Does Nostr fix this? Or are Nostr users already used to unreliable delivery, that it doesn't matter much when they send their data to an obscure relay that no body reads, while all the popular relays are busy?
Login to reply
Replies (58)
Delivery test from mycelium
are you dumb or just pretending to not know how nostr works still?
there is no such a thing as a relay that no one reads, relays are read to the extent that they are used
Purplepag.es is a strange relay to have as an inbox relay
Turns out we both write/read from primal and damus... Who could've thought :)
Do you really think I configure any of this?? I don't even know which app configured that for me.
How does relay obscurity matter as long as events arrive?
If you put in no effort to at least trying to find structure then you will have none.
I intentionally test on Damus as it is high traffic. My personal relays are working fine and I respond to people's inboxes as well as wherever else I want. Discoverability is the responsibility of both network and client architects, and users too.
They won't arrive, your app will tell you that the posting succeeded because it arrived _somewhere_, but it would be like a tree falling in a forest without witnesses. You don't really know which posts got posted to primal and damus and which didn't. But in practice if you don't post to these two, potentially because they are under DDoS, you get worst of both worlds;
1. The service is not available (no one sees your post/reply)
2. You get no indication of failure whatsoever
Nah Email fixed all of these decades ago. Signal/Matrix too gives you perfectly reliable delivery reports. The problem here is that we treat direct conversations as something that should be publicly observable, of course nothing gets observed, so we don't get reliability of Email, nor we get the mythical impossible censorship resistance Reach.
it doesn't matter we just post to the void.
I have delivery reports in mycelium. I failed to publish to purplepag.es as it does not accept kind-1.
If you use the outbox model, and your few outbox servers got DDoSed you still have the same result as Mastodon here. It doesn't matter that you have 3 outboxes instead of 1 homeserver... You are either;
1. Using one paid relays which the same as Mastodon server
2. Using multiple free relays that owe you Nothing and have no promises of resilience.
Nostr is not a reliable network it is censorship resistant network, somewhat, so don't shame people for having popular servers, that is user choice and they get things out of it that they consider more valuable than what you get from Nostr.
If I didn't respond to you, you would have zero way to tell if I read your data, even if it was on my "Inbox" relays, because by the time I check my app, these "inboxes" could have deleted the events as they got evicted from cache... That is not something you expect from Email to happen do you?
Thank you for educating me
I don't really understand the question. With email I don't know if a user has read my message until a response arrives. Delivery confirmation can be verified. If you value having long-term email storage then you would operate your own and create regular backups.
As far as inbox relays- I notice Damus seems to evict events after 1 year of persistence. That isn't bad for free public infrastructure that is easily portable.
No in Email you get an Acknowledgement from the inbox server and emails are not deleted by the server the way open and free relays delete events because they have limited storage. There is a difference between the behaviour of an open relay, and a server with accounts when it comes to data retention.
As for Damus, that is definitely generous, and totally unsustainable without millions of dollars of funding of Nostr mostly by Jack.
But whatever it is fun now. No reason to hate it, I just want to defend more conservative architectures and I don't like when people pretend that Nostr architecture is more resilient when it is not.
I don’t know exactly what I set on Nostur to enable this behavior but I like that it sends my notes to a bazillion relays, in addition to the ones defined by the inbox thing.
But I guess we need to look into the gossip thing.
Well, my TutaMail account was deleted. 😂
The solution to that is censorship resistance decentralised IDs, then you backup your mail. Once the server decline serving you, you upload the backup to a new host, update your DNS records and go on your way. The solution can't be to make a worse system than Email.
I guess being DOS'd is something that Nostr can aspire to.
Read receipts/presence touch on a different problem.
I don’t know about Signal but read receipts are mere events on Matrix land.
We could do the same thing here, not sure if anyone wants it though.
I still like these ideas and I used to consider how to meaningfully combine nostr and pubky.
Some other DHT enjoyer mentioned publishing NIP-65 outbox events to DHT which has minor merit.
But I considered this differently- I used to think, why don't relays have pubkeys?
And so what I consider now is if I mapped relay domains (wss://outbox.mycelium.social) to Pubky keypairs.
Then I would publish the PKdomain to my nip-65 event and have my client favor those domains. Then I could have an unstoppable outbox event that remains updated outside of the network.
No one really gets this stuff but do you think that would actually help anything the way I think it would?
I’m afraid federated protocols such as email and matrix are designed in a way which makes distributed user accounts a subpar experience.
I vaguely remember diaspora* allowing you to replicate the same account across multiple instances, but it wasn’t great.
I think it’s easier to make nostr more reliable than to retrofit distributed ids into existing federated systems.
Right, I forgot those exist. I don't need them personally.
I think the fundamental problem that can't be fixed by Pkarr or any decentralised identity is that both Nostr and Pubky are pull only, there is no Push, as in there is no way to write on someone else's homeserver (maybe Pubky added that by now, I am not following closely), but then allowing Push gets you into the same Email spam problem. So you either depend on some authorities to filter who is a spammer or not, or you just allow only "friend requests" and keep them hidden by default except for a small dot with a number saying you have N friend requests, then you only allow friends to push notifications to you.
But now you are doing what Peergos/Matrix/Signal does, which I think are the correct patterns, but Nostr and Pubky want to imitate Twitter where any stranger (mostly Bots) can reply to you. But at least Twitter has a centralized authority to moderate these. Nostr has none, so I think open networks should lean into the friend requests thing.
At least the first reply from a stranger should be converted to a friend request, just to make sure randos don't get to spam your inbox until you vet them, or if you have enough grace, mark them the way Gmail marks them until you white list them.
At the end of the day, it all comes down to the architecture, do you want the message passing paradigm like ActivityPub or do you insist on the shared Heap paradigm of Twitter and Bluesky but also want to pretend it works for all applications AND can be decentralised?
Sure, but Nostr also doesn't have the best decentralised ID.
Nostr is quite hard to change though, go try to convince Nostr folks that HTTP is quite good actually and websocket is bad default.
Welp, DNS is not censorship resistant either.
If you think about it long enough there are other choke points making the web permissioned and the way out has to include sovereign infrastructure, be it @FIPS , Yggdrasil, cjdns etc.
That's definitely where I prefer nostr to a Reddit/Lemmy format than a Twitter format. I'm more concerned with the protocol being censorship-resistant by proxy rather than architecturally designed as such. I can transmit the JSON pretty freely and thus it is highly censorship-resistant by being easily shareable/broadcastable, and always signed.
The problem of platforms is to weed out this mess and provide infrastructure that more aptly suits the nature of this paradigm.
I think that relay-client codependency is a net negative on the short-term growth model of nostr but overall suits the nature of having an open protocol that is quite flexible in allowing new paradigms to form.
Your suggestion of interaction-based trust models is refreshing.
I don't mind a pull-based model myself, but I also don't think nostr is perfect for realtime chat. However I do foresee possible ways of routing dm's safely without exposing metadata. Perhaps jumping through a few hoops but at a smaller scale it seems trivial.
If I'm not mistaken, Pubky 'Locks' should facilitate the ability for homeservers to granularly permission directories/subdirectories based on other pubkys. This could be one way of facilitating push.
Remember that time when DM observability was announced as a feature...
View quoted note →
Fair point, but @inkan has cooked a key rotation mechanism for nostr.
The problem is that even a half baked dID works better than a permissioned ID, to the point it might get pushed under the rug.
That sounds like a watered down version of WoT, and that’s already something implemented very superficially in nostr currently.
For instance, it feels criminal that following a meme account has the same weight/impact as following trusted individuals.
Key rotation is super easy, at least if you have a strong consistency database to read from like DNS nameservers. Key revocation is the hard part, for example what happens if you give your nsec to a bunker, and it leaks, how do you recover from that? You can't do that without a Blockchain but it is hard to explain why. Try to study Farcaster IDs they did a good job explaining their key management targets
Wait maybe @inkan is actually going in the right direction... I see a mention to a Blockchain... Need to read more, I wish there was an easy link for the architecture
No, WoT requires a public social graph so I know who are the friends of my friends, and even if you can do with with ZK proofs, I haven't seen any evidence of solid implementation that can handle spam well. We have decades of email fighting spam and it boils down to just servers doing their best at heuristic, if WoT was effective you would already have it.
Yeah a long form note would be easier to follow, this thread gives an overview
I don’t think WoT is enough on its own but the friend request thing doesn’t scale alone either.
The attacker has an unlimited supply of identities to spam with “friend requests” (that was/is a problem with Matrix room invites, and that’s only federated system with DNS acting as a prefilter).
He is on the right direction, Ethereum is a bad choice though, and Nostr is even worse choice. This is a common problem with Nostr users and Devs, they use it as a shortcut to avoid building their own gossip protocol, even though in this case the data is scarce enough that a gossip protocol is simple.
I am not sure he has a delayed rotation of the recovery key with the custody key as Farcaster IDs do or not but it is easy to add.
Few things are worth pursuing like history compression with ZK proofs and merklization of the entire state...
There is some indication that he is considering supporting server subsidy of registration, which is definitely the correct direction and should be a first class flow in the protocol.
I am working on something like that in my free time on Rootstock
What about relays cross populating events?
I imagined that as the main structural advantage over the more monolithic instance model.
Damus also recently started showing the associated relays for notes which can clarify visibility if reliable.
This is why you need to use an identity system where creating identities cost something.
Email does this by blacklisting spammy servers so servers have to limit who sign up somehow.
My idea for a cost is basically the Blockchain, basically servers buy a batch of rare limited IDs, and transfer them to users that they have to then audit, because shit isn't free. Of course a determined user can go to the Blockchain directly.
I figure a rate limit of 100K users a day is enough to satisfy even the insane onboarding of Bluesky, while not actually have infinite IDs to burn.
A friend request could be as small as 128 bytes or so, so it is hard to overwhelm a server by requests, and each one costs money, so a spammer is much better off with social engineering some other way.
Cross populating might mean gossip like @Technical Debt says.
What do you all see as the next open social protocol? It seems there are many issues with the Nostr architecture that cannot be fixed with some NIP adoptions by relays or clients. For what it is though, I think it's incredible.
Pubky doesn't seem very clear to me but I do like the DHT approach and credible exit stuff. @Nuh Also brings up some valid critiques and ideas.
So I'm curious what you all think the next steps are :)
But the biggest flaws as @fiatjaf noted in that thread is the unwieldiness of the Blockchain especially Ethereum. I mitigate that by;
1. I don't bloat the Blockchain state so the expense doesn't get out of hand.
2. I use the Blockchain for as little computation as possible to keep the cost low.
3. I only use a smart contract to track an accumulator of previous submitted opaque data.
4. I use Rootstock which is a merge minded PoW chain, so I can have a super light client to find the fork choice.
5. Once I get the light client proof of the latest blocks, I read the accumulator from the contract state, all of that is merkle binary tree stuff, so very light.
6. I ask nodes for the state of any ID, and they give me;
A) the state.
B) a merkle proof from the state to the root of the entire IDs set merkle tree.
C) a ZK STARK proof that given a history that accumulates into the accumulator hash from step 5, you should get a full state with the merkle proof from step B.
This way, light clients don't even have to download the history, neither the history of Bitcoin, nor Rootstock, nor the events published on Rootstock.
At least this is the rough plan, I still need to prove that all this actually works
Even if the influx of invites don’t take down a server, they still annoy the end user and are otherwise indistinguishable from legitimate requests.
Email is an interesting example, just like Matrix they have a DNS prefilter, access to message contents and yet they often decide to drop messages from new/unknown servers.
In principle the system you’ve described could end up needing layers, a domain name is not free yet it is cheap enough not to matter for scammers/spammers.
I also think it’s safe to say the bad guys have a bigger budget than the average user just trying to join the network.
Yeah of course, but think how insane this is, when all I want is to reply to you, instead of just sending you an email like sane people I am supposed to send a packet in the wind and hope for the best?
Even for many to many, which is a very niche case that more or less boils down to Twitter feeds UX, who actually benefits from the insane bandwidth of that gossip? And storage? Who pays for all of that and why? Wouldn't it be infinitely more manageable and cost effective to have things like discord servers and Reddit and group chats etc?
Nostr and Bluesky and Pubky (less so Mastodon because it is aligned with intentional messages passing) are simply intractable and can't both scale and remain decentralised... Because they chose a requirement that is impossible to scale.
Most likely Email. As a general rule of thumb, whatever has been working the longest is the most likely thing to stay. Every thing else is just a passion project.
Yeah but the bad guys also are more likely to be newly registered, but regardless they are also cheap to black list, you just need to subscribe to a good list, or you know, just let them send stuff and don't show them in the app, until the user is reaaaally bored and want to check it.
We need to ask a hot girl on Instagram how does she feel about message requests... Because I don't get many :D
How should we have delivery guarantees outside from silos?
I see Nostr as a balance act, some uncertainty, some redundancy.
I also think sensible messaging probably requires at least one local relay, similar to how personal email requires a local server. Do I make mistakes here?
Blocklists bring back central authorities, hiding everything by default once again risk hiding legitimate requests (hey email also has this issue of putting legitimate senders randomly into the spam folder because of some spam heuristic), at least WoT somewhat alleviates this.
Considering centralization no longer shields from spam (see the comments section of any YouTube video), it’s interesting to see that, as long as you don’t touch public groups, facebook posts don’t get spam, I would say it’s because of the “only friends and friends of friends can comment”.
I don’t know if the Instagram analogy counts though, in that case it’s more of an ego booster and real connections are negotiated out of band.
Again the problem as usual is that you choose a too difficult problem to solve, in this case "reach". Reach will never be solved. Someone will ALWAYS own the audience, no matter what you do, someone will capture the market at least with clients, but before even that, infrastructure is too expensive to decentralise.
If you define the goal as 1-1 messaging or group chat with max 1000 participants, then you already know how to do so without silos, Matrix already did it as flawed as it is, Email more or less too, definitely ActivityPub did well..
All of these could be upgraded with decentralised identity, you don't need to make gossip for these problems... So you know, start with them, and do them reliably and don't start with the Impossible problem then make everything shit because you want everything to use the shitty solution that was the best available for an Impossible problem.
Speaking of out of band, this is something which also happens from time to time. Not sure if it could be handled better.
I don't think unsolicited messages are that important of a problem to solve, and I think just letting everything in (as long as the storage is minimal) then filter them manually or with AI or with a trusted server using TEE, all these are doable.
How many meaningful connections have you had from cold email that could have landed in spam? Not zero but not many.
I also believe that the human way we have always did this and always will be is;
1. I find you in an open forum like this one.
2. We exchange contacts
3. We keep talking to each other way after the forums die, thanks to direct messaging and that phone numbers and emails and stuff like that are actually rarely deplarformed ..
so let's just go all the way on identity, and not worry too much about discovering people, there will always be forums and group chats it is fine.
This would have been a non issue if we had IDs that support recovery like Gnosis Safe and Farcaster IDs.
Seriously Farcaster IDs are the north star but we got to make them actually scalable and censorship resistant without relying on a Rollup that might not exist in 10 years
Umm yes, "many decentralized relay options when the 'big ones' go down" > "I need the one federated server to be online for me to use the network"
Public spaces will eventually rot regardless and the real platform is the friends we make along the way?
Did I understand correctly?
I mean it’s one way of seeing it but I don’t get how it ties back to the conversation.
I am basically making the point that people don't actually need cold emails at all. You can have a situation where you only get messages from people you shared contacts with.
But I am not too committed to this take, I am perfectly happy with 100000 friend requests that I can check at my leisure or through AI at to filter.
Nostr has simplicity, where do the mentioned precursors or competitors have that?
How or why should people work with architecture that offers no motivating or intuitive logic?
I agree we are at the stage where I should write up a proper explanation of what I've done so far. I'll work on that.