Live data from Hacker News

Nostr.how – A Complete Guide to Nostr

nostr.how

31–40 of 140 posts

Re: Nostr.how – A Complete Guide to Nostr

#31
post #12

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.

Why is it designed for iPad? Surely that's always going to be secondary to iPhone use

Did you open the link on a Mac (or maybe desktop overall)?

If so I think it just prefers to show you if it is also optimized for iPad usage, because the usage on a mac would be closer to that.

Re: Nostr.how – A Complete Guide to Nostr

#33
post #8

My previous Mastodon instance (mstdn.plus) broke this week, the administrator MIA, leaving 4500 active users including myself unable to move their followers to new instances or even archive their data: https://lapcatsoftware.com/articles/mastodon.html

Mastodon is essentially centralized — you just pick who you trust with full centralized authority before they have a change of heart, fail, begin rent collecting, whatever. Nobody seems to understand how difficult it is to make a system that can guarantee its neutrality within the protocol. (Sorry HN: it requires crypto.)

Crypto meaning cryptography yes it's needed. If you a referencing bitcoin like technology used for money no they don't help here. Please enough with this "crypto" ignorance

Re: Nostr.how – A Complete Guide to Nostr

#34

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.

Also, if you are interested in trying the many web clients, you could try Nostore: https://testflight.apple.com/join/ouPWAQAV

It’s a Safari extension that will store your keys and sign events for you, so you don’t need to enter them into every web page.

Disclaimer: I wrote it.

Re: Nostr.how – A Complete Guide to Nostr

#35
post #30

I saw this mentioned somewhere else the other day and checked it out. Seems immature to me, something about the lack of structure in their messages, the loose ties to the type enum that they have for messages, feels as if it is not thoroughly thought out.

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.

Re: Nostr.how – A Complete Guide to Nostr

#36
post #19

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 dug into Nostr this week. IMHO, these are some of my engineering concerns. - User accounts are tightly coupled to a single key. There's currently no account abstraction. - Nostr is tightly coupled to a specific crypto primitive and doesn't attempt any sort of crypto agility. - The plan appears that user names are delegated to the centralized DNS system ( https://github.com/nostr-protocol/nips/blob/master/05.md )

> - 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 you refer to)

Do you propose another naming system?

Re: Nostr.how – A Complete Guide to Nostr

#37
post #36
post #19

Earlier quoted context omitted.

I dug into Nostr this week. IMHO, these are some of my engineering concerns. - User accounts are tightly coupled to a single key. There's currently no account abstraction. - Nostr is tightly coupled to a specific crypto primitive and doesn't attempt any sort of crypto agility. - The plan appears that user names are delegated to the centralized DNS system ( https://github.com/nostr-protocol/nips/blob/master/05.md )

> - 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.

Re: Nostr.how – A Complete Guide to Nostr

#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 Twitter migration. The Damus app launch this week brought many relays to their knees. Inevitably as scale becomes necessary relays will centralize.

- Spam, which is free speech in itself, is getting out of control in the relays. Proof of work regulates bots but not crypto spammers.

- The relay construct while powerful, makes it difficult to build real communities with real constructive discourse, which requires some form of moderation. Some might call this censorship.

Re: Nostr.how – A Complete Guide to Nostr

#39

The article doesn't support the claims of how nostr is better than mastodon. From my quick glance at the site, it looks like relays are the equivalent to servers in mastodon, given that it's unclear why relay owners can't also ban you (as they suggest mastodon servers can ban you), why you can't post to multiple mastodon servers simultaneously (similar to broadcasting to multiple relays in nostr) and so on. Nonethele…

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.

Re: Nostr.how – A Complete Guide to Nostr

#40
I’m the dev behind Nostr.how. I’d love to hear your feedback on how I can make the site more clear/better at explaining Nostr.

That said, while I am not the core dev on the protocol or any client/relay it’s been awesome to see the points of confusion from the comments and questions here. Keep them coming - great fodder for new guides.

Post reply on HN