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

21–30 of 140 posts

Re: Nostr.how – A Complete Guide to Nostr

#21

Post by zdragnar »

pkulak wrote: post #14
lazzlazzlazz wrote: post #10

Earlier quoted context omitted.

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

Then host your own instance. Your definition of "centralized" as "optionally requiring any trust at all" is pretty broad, and sweeps up even email.

ActivityPub is a protocol designed for decentralization, but the Mastadon software itself really is not a great option for self hosting. In practical terms, for non-technical users (i.e. the people you need for broad adaptation) self-hosting it is a non-starter.

The same is definitely true for email. There are many providers, so "centralized" is a bit of a loose label, but running your own email server comes with non-trivial pitfalls that keep most people away.

Re: Nostr.how – A Complete Guide to Nostr

#22

Post by leesalminen »

micro_charm wrote: post #3

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.

Re: Nostr.how – A Complete Guide to Nostr

#23

Post by leesalminen »

zdragnar wrote: post #21
pkulak wrote: post #14

Earlier quoted context omitted.

Then host your own instance. Your definition of "centralized" as "optionally requiring any trust at all" is pretty broad, and sweeps up even email.

ActivityPub is a protocol designed for decentralization, but the Mastadon software itself really is not a great option for self hosting. In practical terms, for non-technical users (i.e. the people you need for broad adaptation) self-hosting it is a non-starter. The same is definitely true for email. There are many providers, so "centralized" is a bit of a loose label, but running your own email server comes with non…

The `nostr-rs-relay` package is a simple self-contained rust application with a sqlite db that can run in a docker container. Super simple to self-host and if just using it to save your own notes is more than enough.

https://github.com/scsibug/nostr-rs-relay

Re: Nostr.how – A Complete Guide to Nostr

#24

Post by pointlessone »

leesalminen wrote: post #18
lapcat wrote: post #15

Earlier quoted context omitted.

> It's unclear how to preserve/port data. A relay is supposed to keep (or not) messages and the client is supposed to send messages to multiple relays. But what happens when a relay goes down? Can a client send messages to a new relay? Should the client keep all messages just for such a case? https://www.nostr.how/relays "If all the relays that you have used in the past go offline, all your posts will be unretrievabl…

I think relays should scale horizontally, meaning relays should become topic-based, geography-based, etc. Also, I also don’t think relays are under the obligation to store notes forever. Part of scaling horizontally is hosting your own long term storage (or pay a provider to do that for you). If a relay needs to scale vertically, they could start charging for access or do data mining+ad injection, all kinds of stuff…

How does client decide which relay to send a message to?

Those relay ideas seem like the whole new level of screaming into the void. It doesn’t sit well with me that not only there’s no promise of saving my data but rather ideas of not keeping my data for me are floated around as a normal thing.

Re: Nostr.how – A Complete Guide to Nostr

#25

Post by pointlessone »

piperswe wrote: post #6
micro_charm wrote: post #3

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…

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.

Re: Nostr.how – A Complete Guide to Nostr

#26

Post by leesalminen »

pointlessone wrote: post #24
leesalminen wrote: post #18

Earlier quoted context omitted.

I think relays should scale horizontally, meaning relays should become topic-based, geography-based, etc. Also, I also don’t think relays are under the obligation to store notes forever. Part of scaling horizontally is hosting your own long term storage (or pay a provider to do that for you). If a relay needs to scale vertically, they could start charging for access or do data mining+ad injection, all kinds of stuff…

How does client decide which relay to send a message to? Those relay ideas seem like the whole new level of screaming into the void. It doesn’t sit well with me that not only there’s no promise of saving my data but rather ideas of not keeping my data for me are floated around as a normal thing.

For this to happen clients will have to build this into the UI. I’ve got a work in progress concept for one client [0]. Basically let a user create arbitrary relay groups. When posting the user can choose which groups to post to. Users can then filter their feeds to specific relay groups.

[0] https://github.com/monlovesmango/astral/pull/93

Re: Nostr.how – A Complete Guide to Nostr

#27

Post by leishman »

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.

Re: Nostr.how – A Complete Guide to Nostr

#28

Post by lapcat »

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.

Yes, this aspect seems problematic.

> to "follow" someone a user just instructs their client to query the relays it knows for posts from that public key.

Re: Nostr.how – A Complete Guide to Nostr

#29

Post by leishman »

dom96 wrote: post #12
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.

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

It works on iPad afaik but isn’t natively built for it. Also works on macOS.

Re: Nostr.how – A Complete Guide to Nostr

#30

Post by therein »

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.
Post reply on HN