Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nostr.how – A Complete Guide to Nostr

nostr.how

Post reply on HN
Print view View original

71–80 of 140 posts

Re: Nostr.how – A Complete Guide to Nostr

#71

Post by CodexArcana »

therein wrote: post #55
ursuscamp wrote: post #35

Earlier quoted context omitted.

It’s something we’re building in real time, as we use it. If you visit the NIPs repo, you will see it changing by the idea. As the clients and relays try things, ideas propagate quickly. In that sense it is extremely exciting.

It is definitely interesting and exciting, at least the end goal. I am still not sold on the architecture but I want to be. So relays are not able to talk to one another and if I want to be able to interact with another user in any way, we have to be sharing a relay, right? These seem like really strong limitations to me and I am having a hard time understanding why they exist. Why not start with some relay-to-relay…

Relays are not prohibited from communicating with each other. There just isn't a defined and agreed on method to do so. Maybe there never will be. But that doesn't mean you can't build a relay server that has a replication feature. It would simply be proprietary.

Re: Nostr.how – A Complete Guide to Nostr

#72

Post by nine_k »

gtirloni wrote: post #60
gray_charger wrote: post #7

Earlier quoted context omitted.

I think centralized moderation is the problem with social media servers. Users should be the ones to control their own moderation. See a post you don't like? Hide the post. Don't like any posts from a particular user? Block the user. It's not difficult to do and if users are really only following friends and famous accounts (celebrities, bots, news, etc.) they won't experience much spam anyway. I think the real issue…

Saw some CP, just block it, right? No one to be notified so it stops spreading.

That's how technology works. If it works for you, it works for your most bitter opponent. If it limits your opponents, it also limits your dearest friends.

Choosing the right amount of freedom is always a balancing act.

Re: Nostr.how – A Complete Guide to Nostr

#73

Post by leesalminen »

kemitchell wrote: post #65
pointlessone wrote: post #13

I read everything there and all NIPs (they look like underage RFCs, but also drunk) and I'm a little confused. - The protocol doesn't define a transport but seem to use WebSockets. How does it handle poor/dropping connections? Does it allow usage of alternate transport protocols? - Messages are defined as JSON but doesn't use much of its structure anyway. Some fields are just arrays of values. And even then some part…

> Message signatures are signatures of stringified JSON. Given that JSON is not particularly well defined to guarantee representation stability are implementation differences handled? Systems I've seen (and written) that do this use deterministic serialization algorithms that sort keys and do other things standard, general-purpose implementations don't. The implementations in core libraries, browsers, and the like te…

Taking a look at NIP-01, the serialized data that gets hashed and signed is a flat array, not an object. So no sorting of keys here. I don’t think any json serializer would change the order of items in an array, right?

https://github.com/nostr-protocol/nips/blob/master/01.md

Re: Nostr.how – A Complete Guide to Nostr

#74

Post by leesalminen »

dack wrote: post #66
erskingardner wrote: post #39

Earlier quoted context omitted.

Yup spot on. The main issue though is that if you want to ensure that you have absolutely unassailable content, you need to run you own relay that ensures all your events are stored. You can’t assume that the relays you connect to via clients are perfect. I imagine relay services will get better over time here but something to be aware of.

I don't quite understand why a client can't do it's own backup... it's really not that much data i would think. you could sync it to google drive or equivalent, and while your posts may temporarily be unavailable if all the relays are down, you could theoretically re-populate another relay (or your own) with that backed up data right?

A client can do this. There’s nothing stopping this from being implemented. I think it’s a good idea, really. It’s just a PR away from becoming reality :).

Re: Nostr.how – A Complete Guide to Nostr

#75

Post by leesalminen »

Aeolun wrote: post #64
legutierr wrote: post #63

Earlier quoted context omitted.

The search function can help you find accounts. Your timeline is generated from who you are following. Follow some people and it gets more interesting.

I missed the global function. After blocking a bunch of spammers it seems better. Still seems like they generate new PK’s once in a while though, so it’s impossible to keep up.

I use global to find some posts of real people, then go through their profile and decide whether to follow or not.

Also https://nostr.directory helps me find people on Twitter in nostr.

Took a bit I’m happy with my normal feed now and use Global less and less.

Re: Nostr.how – A Complete Guide to Nostr

#76

Post by jensensbutton »

Aeolun wrote: post #59
galleywest200 wrote: post #53

Earlier quoted context omitted.

> I can't select whom emails me. If you are in control of your mail server you can block email addresses, even entire domains or IP spaces. I do not understand this statement.

Email is push. Twitter is pull. Of course you can set your email server to reject every single email that you do not have in a whitelist, but that’s not a feature of the protocol. Plus it’s something you need to manually do (because most people don’t want -or expect that- from email). People expect Twitter (or similar apps/protocols) to not show them messages other than from people that are explicitly followed.

No they don't. Twitter hasn't done that (restrict your feed to only people you follow) in a long time.

Re: Nostr.how – A Complete Guide to Nostr

#77

Post by leesalminen »

leishman wrote: post #27
pointlessone wrote: post #13

I read everything there and all NIPs (they look like underage RFCs, but also drunk) and I'm a little confused. - The protocol doesn't define a transport but seem to use WebSockets. How does it handle poor/dropping connections? Does it allow usage of alternate transport protocols? - Messages are defined as JSON but doesn't use much of its structure anyway. Some fields are just arrays of values. And even then some part…

I’ve built a Nostr relay from scratch to learn the protocol and while there are some odd quirks, the fact that it’s maximally simple and the core spec can be understood in 5-10 minutes has way more value than you may immediately realize. It lowers the barrier to entry for builders substantially.

I also had a similar experience. I’ve built a handful of little things that speak nostr over the past month just to get a feel for it.

Time-to-grok is fast and then you’re off to the races building.

I never even bothered to build anything on ActivityPub because the minimum bar is much higher.

Re: Nostr.how – A Complete Guide to Nostr

#78

Post by leesalminen »

gtirloni wrote: post #60
gray_charger wrote: post #7

Earlier quoted context omitted.

I think centralized moderation is the problem with social media servers. Users should be the ones to control their own moderation. See a post you don't like? Hide the post. Don't like any posts from a particular user? Block the user. It's not difficult to do and if users are really only following friends and famous accounts (celebrities, bots, news, etc.) they won't experience much spam anyway. I think the real issue…

Saw some CP, just block it, right? No one to be notified so it stops spreading.

Damus currently has a report note button which broadcasts another event with a specific kind ID. Anyone could connect to relays and collect all the IDs of reported notes and do either good or bad things with this information. Other clients can add this button too, and can choose to not display previously reported notes (above a threshold etc).

Re: Nostr.how – A Complete Guide to Nostr

#80

Post by leesalminen »

Aeolun wrote: post #61
dkobia wrote: post #38

I’ve been using Nostr, Mastodon and Twitter concurrently for the last few months. Nostr is absolutely fascinating in its simplicity and I really enjoyed writing a Python relay in a few days - more than I should have. My thoughts: - The NIPS are not as rigorously defined as RFC's but this is a vibrant community and things are taking shape. - Relay scaling will be a problem, something Mastodon has discovered with the T…

As it is it seems like very basic spam measures would be enough to cut down on almost all the spam in relays.

Damus recently added a Report button. This button broadcasts a new event of a specific kind to relays with the offending note ID. Other relays/clients are free to take spam measures with this user generated data.
Post reply on HN