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.
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)
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.
At the top, sure, but our machines have their own DNS so we could get around the ICANN DNS servers if we told our machines to do so. Is that what ENS is?
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.
> The protocol doesn't define a transport but seem to use WebSockets.
The protocol transport is over WebSockets.
> How does it handle poor/dropping connections?
The way HTTP underneath it handles poor/dropping connections. It is request-response like HTTP, there isn't state to recover, just try again.
> Does it allow usage of alternate transport protocols?
If you think it is useful, write a NIP for it.
> 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.
Being readable is helpful for debugging. I agree there is less structure than could be used, but it is well-defined and libraries can more strongly type the data and name the fields, for example. One thing you can't easily do is go back and change the protocol, that would create far too much complexity.
> Message signatures are signatures of stringified JSON. Given that JSON is not particularly well defined to guarantee representation stability are implementation differences handled?
The part that is signed is defined well enough that at least dozens (probably near a hundred now) coding implementations are inter-operating on this without issue. Is the definition formal and rigid enough to ensure nobody misinterprets it? Probably not. I've had to ask for clarification and when I got it, I put in a PR to change the NIP. It was accepted right away.
It is not XMPP. Have you read the XMPP RFCs? I couldn't even get through the table of contents of the first one. The guiding principle of nostr is that it is the simplest protocol that has a chance of working.
> 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?
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
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.
> 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.
Taking a look at NIP-01, the serialized data that gets hashed and signed is a flat array, not an object. So no sorting of keys here. I don’t think any json serializer would change the order of items in an array, right?
That's true but there's still plenty of room for incompatibility. JSON doesn't put any requirements on floats precision, for instance. Another example is that any character may be escaped (that's in the RFC, literally, verbatim) so while it's recommended to use UTF-8 for serialization a random lib can decide that ASCII is the way and escape all your emojis. To be fair, NIP-01 specifies that it has to be UTF-8 but no mention of float precision can be found. I'm almost certain these two are not the only ways a JSON can be divergent while still being valid.
And I have to point out that we're doomed to repeat our mistakes. XML is also very flexible. And people wanted to sign XML documents and they found this to be a problem. So they came up with Canonical XML form — a way to remove some of that flexibility to make sure it's possible to reliably derive a stable variant that can be signed and verified. Unfortunately, we haven't came up with Canonical JSON yet. But maybe we will soon.
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.
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.
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".
These notes can already be flagged and reported. This action generates another note of a specific type. A nostr client could use this data and hide notes from users before they ever see them.
> These notes can already be flagged and reported. This action generates another note of a specific type. A nostr client could use this data and hide notes from users before they ever see them.
This is just crowdsourced moderation then? Which relies heavily on there not being bad actors that can be incentivised to run up botnets to generate bogus flags/reports to push their own agenda.
Damus currently has a report note button which broadcasts another event with a specific kind ID. Anyone could connect to relays and collect all the IDs of reported notes and do either good or bad things with this information. Other clients can add this button too, and can choose to not display previously reported notes (above a threshold etc).
That's how technology works. If it works for you, it works for your most bitter opponent. If it limits your opponents, it also limits your dearest friends.
Choosing the right amount of freedom is always a balancing act.
Of course you can set your email server to reject every single email that you do not have in a whitelist, but that’s not a feature of the protocol. Plus it’s something you need to manually do (because most people don’t want -or expect that- from email).
People expect Twitter (or similar apps/protocols) to not show them messages other than from people that are explicitly followed.
There is a "Following" tab which is supposed to be just tweets from those you follow (and things they interact with), compared to the "For you" tab which is curated by "the algorithm". I'm pretty certain there has always been a way to filter the timeline down to just people you follow.
> But this isn't an alternative to Mastodon or Twitter, it's an alternative to Berty, Cwtch, Speek, Briar, Anonymous Messenger, and maybe Matrix
And (not maybe) xx Network.
Nostr isn't an alternative to these messaging and chat apps because it has weak anonymity and privacy. Take a look at how those other apps/platforms work, and then compare them with Nostr.
> As such, it comes to no surprise that the free speech warriors from the crypto community are the main drivers of this protocol.
Nostr has weak privacy protections compared to most of of the above mentioned platforms, so I don't think it's something free speech advocates should feel comfortable promoting - anyone who truly needs free speech and uses Nostr won't last long.
So far, there haven't been many "bad and toxic actors". I have met one bad actor among thousands on nostr and I muted him. I heard there was porn in global chat, but my client doesn't even offer global chat.
People don't consider their relays "hostile", but they don't trust them with things they don't need to trust them with. That's not the contradiction you imagine. Relay operators are trusted with things like spam filtering, illegal content removal, etc. One method is that a proof-of-work is required to start writing to a relay, and your public key can be banned quickly for bad behavior, resulting in another long proof-of-work to try again.
Trusting a relay with account management, for example, is horrible. Trust as little as necessary.
> So far, there haven't been many "bad and toxic actors"
It's also obscure enough to not even have a Wikipedia article, the "first & best iOS client for Nostr" wasn't published on GitHub until less than a year ago (but wasn't in the app store until this week according to another comment), the Android client they recommend wasn't on GitHub until last month, and the web client they recommend (Iris) didn't add Nostr support until 2 months ago. Edward Snowden seems to be the most prominent user, and he has 5 followers. I don't know if this is broken, because it seems a ridiculously low number, but that's what it displays.
There's lots of things that work well at small scale, but not so well at scale.
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.
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
Think of cryptos more like “incentives to rational behavior” than “money” and it starts to make sense. You can incentivize, for example, data availability with cryptos and that opens the design space for distributed systems that don’t need to be controlled by one entity (like Twitter, for example).
There are two places where a blockchain would be very useful in this context: guaranteeing completeness (allowing you to confirm whether or not you have downloaded all the posts ever created by a user), and preventing timestamp forgery.
SSB has something like this but it requires a user to download another user’s entire post history before being able to see one post. Makes the experience very slow.
Crypto movement does not relate to bitcoin. Bitcoin was about preventing money printing and crypto is about every VC having his own private money system he sells token of
I didn't say decentralised timestamping is required for a social network or any blockchain needed
How do you guarantee data availability and avoid double spending without Byzantine fault tolerant consensus (that is, blockchain crypto)? If you have an answer you will be onto something huge.
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.
Use Pleroma instead of Mastodon, it is quite easy to host and only takes a fraction of the resources Mastodon does - it idles at 165 MB on my test instance (single user logged in, no activity). From what I've seen it should possible for non-technical people to self-host it as long as there is a possibility for remote-access assistance (and there's your business model, sell wall warts with self-hosted services with optional remote assistance).
That said I do prefer a mail-based system like Delta Chat [1] over these ActivityPub-based things since everyone already has a mail address and there is a wide range of software to choose from.
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.
This is why I installed my own Pleroma instance (immibis@social.immibis.com). It's not very difficult. I hear Mastodon is much more painful to install.
It may need cryptography. I think the majority of HN likes cryptography. When you say crypto, and apologize for it, I assume you mean the stupid coins and all the nonsense that comes with that group of fools, and that is not required.
Gateway operators are paid to successfully process data (which they can do if they stay online, have a fast connection to the Internet, and so on - not a shitty Raspberry Pi)
Gateway operators are paid to store data
Gateway operators are paid to mix client-side encrypted messages and shred message metadata
Gateway operators are staking their nodes to ensure cryptographically correct operation
If you want to see more, spend some time reading how blockchain-based networks with incentives work.
That describes most centralized services on the web today. Nostr and other decentralized protocols aren’t aiming to recreate the Twitter and Amazon model.
These services exist outside of the protocol and depend on a few centralized and trusted authorities.
Another solution that is arguably more resistant to capture and censorship would be to use a blockchain to manage user name aliases - like Farcaster is doing with fnames.[1]
Consensus isn't a fundamental requirement for social media or a communication protocol. Email doesn't require a blockchain and doesn't care about 'double spending' or whatever.
The previous comment didn’t ask for consensus for a social media or communication protocol specifically but rather was two steps ahead and was referring to the infrastructure that those protocols run on. Under the hood, there are various consensus mechanisms in current day social media or communication protocol infrastructure systems and those systems are needed to make sure (user) data is available. In order to run a data availability system, there’s a consensus required somewhere there. If you want to have the infrastructure provider run it “honestly”, in a protocol sense, then you need incentives for them to do so. If you need incentives, then you need kind of transactional system in a payment and accounting system sense. And that’s where you then need to care about “double spending”.
Did email ever manage to become largely decentralized? Most people use centralized services like gmail, and pay for it with their privacy. It's not viable for the majority to have their own servers
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.
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.
Damus recently added a Report button. This button broadcasts a new event of a specific kind to relays with the offending note ID. Other relays/clients are free to take spam measures with this user generated data.
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
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?
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.
This is a current problem. The solution is sending a small message telling everyone where you post to lots and lots of relays, then just posting to a few of them.
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?
A client can do this. There’s nothing stopping this from being implemented. I think it’s a good idea, really. It’s just a PR away from becoming reality :).
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.
It’s not really related to Bitcoin but it uses the same crypto primitives, schnorr signatures, secp256k1 elliptic curve etc, if you are building for nostr you can reuse the numerous bitcoin libraries. As a result it’s trivial to implement support for lightning network payments.
It’s trivial to implement support for Lightning network payments virtually anywhere at this point. Damus isn’t using any crypto primitives directly to have a pay button.
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.
Nostr "relay" nodes have no economic incentive to relay and store data.
Because of that, authors and readers of least popular opinions - which may be legal content that's censored elsewhere - are most likely to be easily identified and tracked.
No incentive to store data, no incentive to relay data, weak privacy, no censorship resistance, relay nodes may be legally responsible for knowingly relaying data from accounts censored by the rest of the network, etc.
For Nostr relay nodes it's like running a Tor Exit node where you may be the only exit node for illegal content.
And for users it's like using Tor to browse the Internet thinking your metadata isn't being captured, without knowing there's just 1 or 2 exit nodes out there.
There are no privacy and pseudo-anonymity advantages over "Twitter over Tor".
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.
It is definitely interesting and exciting, at least the end goal. I am still not sold on the architecture but I want to be.
So relays are not able to talk to one another and if I want to be able to interact with another user in any way, we have to be sharing a relay, right?
These seem like really strong limitations to me and I am having a hard time understanding why they exist. Why not start with some relay-to-relay capabilities as well like XMPP has?
Relays are not prohibited from communicating with each other. There just isn't a defined and agreed on method to do so. Maybe there never will be. But that doesn't mean you can't build a relay server that has a replication feature. It would simply be proprietary.
With the rise in decentralized social networks I was expecting a lot more tastemakers to emerge. People who are not influencers in the current sense but more like old social column writers which told us the best clubs or restaurants in the city. Are there people publishing list of people worth following or something along those lines?
Honestly, I don't get the fuss about these "libertarian-inspired social network protocols". It's not like the technical side of social media is the tough one: it's always been the political and sociological one.
In the end, most people aren't hardcore libertarians and do want content moderation, centralized discovery, spam blocking... I would really find it interesting if it came about a protocol that actually cared about those things and provided a way to handle them other than a megacorp doing all of it. But all those protocols operate under the assumption that people are okay with seeing really bad things that real people come up with (even CP like commented elsewhere in this thread) themselves under the guise of "full decentralized liberty".
I suspect that's why they all ultimately fail or at least remain niche things. If the alternative to megacorps is this wild west, people will remain in the megacorps' social media.
There's nothing about nostr that prevents any relay and/or client from offering these things (content moderation, centralized discovery, spam filters). They could even share their findings with other relays/clients and build one big cohesive censorship system.
If this happened, users would be free to opt-out of that and switch out their client and/or relay with other options that fit their needs without friction. They would keep their identity, note history, friend list, etc.
Could be as simple as one client releasing a UI change the user hates. They could just download a different app and keep going.
Nostr is being built right now. We’d love for you to join us, it’s just a PR away!
To be clear, Damus already offers some level of content moderation. Other clients are accepting PRs to implement as well. Nostr itself offers some level of centralized discovery with NIP-05. Relays are starting to look at spam filtering (via pay-to-post models mainly).
it's not even a social networking protocol, it's literally just a networking protocol for the reasons you laid out.
And of course all the dynamics you talk about emerge naturally. With scale comes concentration and hierarchies out of necessity, the power to blocklist 'relays' across the largest instances, etc.
All these experiments basically are a venture in rediscovering economics and politics. The internet started out decentralized. Reinventing html and web servers isn't changing anything.
A good Mastodon instance can certanly provide what you say most people'd want. Since it's activitypub, you wont be locked in to mastodon only. And since it's foss, account migration will probably be worked on as it's the #1 critique of Mastodon (aside of onboarding).
I don’t think so. Blockchain is an append-only log with consensus, and Nostr doesn’t need the consensus part because it’s not harmful if clients disagree about the state of the data. However, client data is signed with Nostr which is awesome, so you can easily tell whether something is legit. If a client or a relay misbehaves it’d be very easy to tell. I really love this architecture.
IMHO blockchain is an ugly terrible solution to a problem that had no other solution. The chain just gets bigger never smaller, requires expensive proof of work, requires complex synchronization protocols. Why so many people want to copy the worst part of bitcoin for their new billion dollar startup idea has always been beyond me.
- 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.