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

61–70 of 140 posts

Re: Nostr.how – A Complete Guide to Nostr

#61

Post by Aeolun »

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.

Re: Nostr.how – A Complete Guide to Nostr

#62

Post by pessimizer »

pointlessone wrote: post #25
piperswe wrote: post #6

Earlier quoted context omitted.

With Nostr, your identity isn't attached to a relay, so if one relay doesn't like you other relays will still relay your content, while still keeping your followerbase

How would my followers (or whatever they’re called in nostr) know where to get my events from? It seems like optimal strategy is to send to/fetch from every relay possible. Effectively, every relay would host the whole network. In this regard federation seem a little more scalable.

> How would my followers (or whatever they’re called in nostr) know where to get my events from?

I don't know anything about Nostr, but couldn't that easily be solved by adding the relays that you use as a field in your event? Or even using a DHT to find relays that carry content from a particular user?

Re: Nostr.how – A Complete Guide to Nostr

#63

Post by legutierr »

Aeolun wrote: post #54
legutierr wrote: post #2

If anyone is interested in trying out Nostr, I would recommend downloading Damus, the iOS client that’s currently available. https://apps.apple.com/us/app/damus/id1628663131 It’s not perfect, but it feels a lot like the Twitter iOS client, and gives you an idea of what Nostr can become.

> what Nostr can become. A timeline of a single person (Damus) shouting into the void?

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.

Re: Nostr.how – A Complete Guide to Nostr

#64

Post by Aeolun »

legutierr wrote: post #63
Aeolun wrote: post #54

Earlier quoted context omitted.

> what Nostr can become. A timeline of a single person (Damus) shouting into the void?

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.

Re: Nostr.how – A Complete Guide to Nostr

#65

Post by kemitchell »

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 tend to be faster, but the payloads being signed in the apps usually aren't that large.

Re: Nostr.how – A Complete Guide to Nostr

#66

Post by dack »

erskingardner wrote: post #39
leesalminen wrote: post #22

Earlier quoted context omitted.

The main difference is that on mastodon your identity is tied to the server you registered on. So, if a mastodon server bans you, you lose your account, your friends list, and your post history. On nostr, your identity is a key pair and not tied to any particular relay. If a relay bans you, you can just connect to a new relay, re-broadcast your old notes to it, and keep going. Your friends list stays in-tact.

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?

Re: Nostr.how – A Complete Guide to Nostr

#67

Post by 21eleven »

gray_charger wrote: post #7
class4behavior wrote: post #4

The whole premise of Nostr is that you consider your access point hostile, yet its provider is still offering one. That contradiction just incentivizes bad and toxic actors to participate and dominate this network. That's why, it seems, the developers actively conflate what one would expect from a private communication platform and a social media platform. But this isn't an alternative to Mastodon or Twitter, it's an…

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…

Discovery could be done via "retweet"/repost functionality. Perhaps there could be some feed of most reposted over the last day.

Just spit ballin

Re: Nostr.how – A Complete Guide to Nostr

#68

Post by CodexArcana »

pointlessone wrote: post #25
piperswe wrote: post #6

Earlier quoted context omitted.

With Nostr, your identity isn't attached to a relay, so if one relay doesn't like you other relays will still relay your content, while still keeping your followerbase

How would my followers (or whatever they’re called in nostr) know where to get my events from? It seems like optimal strategy is to send to/fetch from every relay possible. Effectively, every relay would host the whole network. In this regard federation seem a little more scalable.

I don't know if clients support this yet but you can transmit a suggested relay with your post that people can add to their list of relays. That suggested relay should be one you control. That way they always have a point of truth for your notes.

Re: Nostr.how – A Complete Guide to Nostr

#70

Post by nine_k »

Zamicol wrote: post #37
evv wrote: post #36

Earlier quoted context omitted.

> - The plan appears that user names are delegated to the centralized DNS system ( https://github.com/nostr-protocol/nips/blob/master/05.md ) DNS is not centralized, it is distributed. A name server can delegate authority to other servers. Every nation has their own, which I consider sufficient decentralization. (Although it does rely on IANA to list addresses of root name servers, which is perhaps the centralization…

DNS is centrally controlled by ICANN. There are alternatives like ENS. I don't mind Nostr just simply having its own system.

DNS is both.

There are the universally accepted root servers, ICANN, national registrars, etc.

But nothing prevents you from trusting additional root servers, with TLDs if your choice, delegation of subdomains from them, etc. All the standard mechanisms will just work. Your router likely supports the .lan TLD out if the box.

Post reply on HN