[HN Gopher] Nostr.how - A Complete Guide to Nostr
___________________________________________________________________
Nostr.how - A Complete Guide to Nostr
Author : vmoore
Score : 64 points
Date : 2023-02-04 18:49 UTC (4 hours ago)
(HTM) web link (www.nostr.how)
(TXT) w3m dump (www.nostr.how)
| pointlessone wrote:
| 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.
| leesalminen wrote:
| > 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.
| lapcat wrote:
| > 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?
| leesalminen wrote:
| 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
| pointlessone wrote:
| 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.
| leesalminen wrote:
| 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
| Zamicol wrote:
| 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)
| leishman wrote:
| 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 that you may immediately realize. It lowers the
| barrier to entry for builders substantially.
| legutierr wrote:
| 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.
| dom96 wrote:
| Why is it designed for iPad? Surely that's always going to be
| secondary to iPhone use
| micro_charm wrote:
| 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.
|
| Nonetheless it's good to see the broader adoption of "account
| creation as equivalent to public/private key creation" in social
| media services
| piperswe wrote:
| 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
| pointlessone wrote:
| 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.
| leesalminen wrote:
| 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.
| lapcat wrote:
| 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
| class4behavior wrote:
| 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.
| lazzlazzlazz wrote:
| 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.)
| pkulak wrote:
| Then host your own instance. Your definition of "centralized"
| as "optionally requiring any trust at all" is pretty broad,
| and sweeps up even email.
| zdragnar wrote:
| 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.
| leesalminen wrote:
| 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
| class4behavior wrote:
| 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 alternative to Berty, Cwtch, Speek, Briar,
| Anonymous Messenger, and maybe Matrix if you use it for encrypted
| communication only.
|
| It has a legitimate use case for people who may be forced to
| switch relays very often due to government censorship but still
| want to continue to talk in public. To anyone else the quality
| and culture of the moderation system is what defines the quality
| of their platform, but Nostr undermines the former by design.
|
| As such, it comes to no surprise that the free speech warriors
| from the crypto community are the main drivers of this protocol.
| It's just a pity that Snowden seems to have become one of them as
| well - and it isn't that he supports it, but how. He's just
| repeating the devs' own flawed narrative.
|
| Decentralization is the right path forward, but you want social
| media on federated platforms as you need to take care of
| communities with enforceable rules and provide a service to
| users, while for private interpersonal or group communication you
| can opt to federated or peer-to-peer networks.
| solarkraft wrote:
| > The whole premise of Nostr is that you consider your access
| point hostile, yet its provider is still offering one.
|
| I'm confused. Doesn't this apply to a lot of projects offering
| hosting for E2EE services? Why should it be a problem?
| class4behavior wrote:
| As I said in my post - if you read it - private communication
| and social media are not the same. The expectations are
| different. On a social media platform you want some level of
| persistence, you want someone to be able to nurture a healthy
| discussion culture.
|
| But if all of your users were just fine, there are barely any
| advantages over a federated platform where you can migrate;
| much more disadvantages instead.
| gray_charger wrote:
| 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 is discovery. How does one find other
| accounts that post about similar topics (other than friend-of-
| a-friend approach) and that aren't spam.
| lapcat wrote:
| 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".
| leesalminen wrote:
| 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".
___________________________________________________________________
(page generated 2023-02-04 23:00 UTC)