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

11–20 of 140 posts

Re: Nostr.how – A Complete Guide to Nostr

#11

Post by lapcat »

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…

AFAICT at first glance, on nostr you would only see posts from accounts you follow. There isn't any "algorithm" to feed content to you. Someone can correct me if I'm wrong, but this is my impression. Therefore, it's all self-moderation, and you wouldn't have any spam or messages from hostile randos, because you wouldn't be following them in the first place. And as you say, "the real issue is discovery".

Re: Nostr.how – A Complete Guide to Nostr

#12

Post by dom96 »

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

Re: Nostr.how – A Complete Guide to Nostr

#13

Post by pointlessone »

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 parts are just strings with some other arbitrary syntax. Seems like a poor choice.

- Message signatures are signatures of stringified JSON. Given that JSON is not particularly well defined to guarantee representation stability are implementation differences handled?

- Messages are just sent around without any delivery confirmation. There's a NIP to introduce delivery confirmation from the client to relay. And then there's another NIP to signal completion of messages retrieval from the relay. Both are optional.

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

Overall feeling after reading all that is it's XMPP but worse. It's worse defined. It's not quite decentralised as there's a single point of failure: relay. And it's unspecified how to handle demise of a relay and port data to another relay. Signing and encryption is nice but message structure makes me feel dirty. XMPP wasn't inititally meant for a decentralised public messaging but there are a few XEPs that do exactly that, as well as signing and E2E encryption. And all other good stuff like BOSH (XMPP over HTTP), for example.

Re: Nostr.how – A Complete Guide to Nostr

#14

Post by pkulak »

lazzlazzlazz wrote: post #10
lapcat wrote: 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.)

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

Re: Nostr.how – A Complete Guide to Nostr

#15

Post by lapcat »

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…

> 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 unretrievable. This is one reason that Nostr allows users to connect to many relays – this ensures some degree of backup. That said, if you're really interested in being uncensorable, you can run your own personal relay."

So clearly, relays are retaining copies of your data. The question is really storage capacity: if nostr becomes popular, will individual relays have enough storage capacity for all of its users?

Re: Nostr.how – A Complete Guide to Nostr

#16

Post by class4behavior »

lapcat wrote: 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

On Nostr, just the migration is easier, but you still need to have your data stored on your device or somewhere else. In turn you communicate with a lot more servers (privacy), those servers have much less incentives to moderate, even if you pay them, or earn its communities trust - hence all the ads and tracking already in place.

Re: Nostr.how – A Complete Guide to Nostr

#17

Post by leesalminen »

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…

> Can a client send messages to a new relay?

Yes, a user can transmit a previously created note to a new relay at any time.

Re: Nostr.how – A Complete Guide to Nostr

#18

Post by leesalminen »

lapcat wrote: post #15
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…

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

One of the writers of the NIPs posted this earlier today:

> Other relay ideas (not very good, just to sparkle your imagination):

- a relay only for people with top-level domain names (no "@" at the NIP-05)

- a relay that only stores the most recent post of people

- a relay that only stores posts that have received at least 10 replies from other people (big threads)

- a relay that only serves posts to people having $X tag on their profile metadata

Re: Nostr.how – A Complete Guide to Nostr

#19

Post by Zamicol »

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

Re: Nostr.how – A Complete Guide to Nostr

#20

Post by leesalminen »

lapcat wrote: post #11
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…

AFAICT at first glance, on nostr you would only see posts from accounts you follow. There isn't any "algorithm" to feed content to you. Someone can correct me if I'm wrong, but this is my impression. Therefore, it's all self-moderation, and you wouldn't have any spam or messages from hostile randos, because you wouldn't be following them in the first place. And as you say, "the real issue is discovery".

That's all that exists today. Nothing prevents a client from developing some sort of algorithm, querying the relays appropriately, and rendering notes from users not followed.

At the same time, nothing prevents a user from migrating to a different client that has no "algorithm".

Post reply on HN