Oddbean new post about login | logout The outbox model still needs to gain significant adoption across Nostr's most popular clients. I had hoped that by the end of 2024 we would see mass adoption. The clock is ticking to meet this goal, but I feel we're on track. Why is this important? This will shift the focus away from relying on a small number of dominant relays, leading to a more decentralized and resilient network. Beyond increasing decentralization, the implementation of the outbox model significantly contributes to the long-term sustainability of the Nostr protocol too. This is achieved by alleviating the burden on relay operators, who would no longer require substantial resources to maintain large-scale infrastructure. This paves the way for long term, small community focused relays. Small relays such as Nostr Team Relay or Ditto powered instances could be part of Nostr's core future. No longer would users need to center upon the top relays to communicate. Individuals could run their own private relay and only post to their own private relay and/or a couple others. Which clients have support? Clients perform the heavy lifting here, facilitating all of these improvements. Several already do, and others are working on implementation. Full or partial support: Gossip Snort Iris Coracle Nostrudel Lume Amethyst Highlighter And any applications built with NDK. Future support: Damus, including Notedeck Primal If this list is inaccurate or needs updated please let me know.
and thoughts on community security? Literally the only person who actually engages me on this topic is nostr:nprofile1qqsyeqqz27jc32pgf8gynqtu90d2mxztykj94k0kmttxu37nk3lrktcpz9mhxue69uhkummnw3ezumrpdejz7qg3waehxw309ahx7um5wgh8w6twv5hsz9mhwden5te0d4kx26m49ehx7um5wgcjucm0d5hspyest0 because he vehemently opposes a perspective I have but we gucci otherwise. nostr:nevent1qqsdynz4nvh6k62cexwjl5nwuf67xw5xmnr90utx2qnh6y8p8wp25fgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsdcnxssmxheed3sv4d7n7azggj3xyq6tr799dukrngfsq6emnhcpsrqsqqqqqpj2s0gu
i think echo chambers are bad. but what does this have to do with community security? what am i missing?
keeping people connected and not letting them get fragmented i'm still gonna keep liminal blocked and unfollowed until he understands there is nothing benign about the trans agenda tho
If you want to be an asshole be an asshole on your relay, but you can still be on my relay if you follow my rules. Specialized communities wont come to nostr if anyone can comment on their content because of the chance of vandalism. Nostr itself is an echo chamber and anyone veering from the average perspective is ganged up on disencentivizing others away. switch relays for specifc topics, or groups multiple relays together for different communities. Just like amethyst uses lists to follow hashtags you can do that for relays. Famous user posts, incoming reboost cascade. I get it, I already saw it five times. you can of course have any mix of relays you want and relays that have loose moderation tools thats perfectly fine and now boosting is less annoying if you're cross posting across communities. Reporting is actually actionable because it holds moderators/relay operators accountable for user behaviors because no one likes a community garden where anyone can shit there as they please. its not about "forcing" an echo chambers, its allowing a gradient level of openness.
This first paragraph sounds like Fediverse. Communitites and relays shouldn't be a 1:1 relationship. Probably a many:many.
Yes, and we should have it but our data shouldn't be beholden to any single relay operator as the fediverse has it.
i guess technically a relay could only allow reading and writing from authorized npubs or they could do heavy filtering to only show content from specific npubs. this is almost similar to what Ditto is doing with their community instances.
I argue that you get the most bang for your development time with relay selection and whitelisted relays.
I would agree here that relay management is key, but I also understand that most people don't want to configure their relays and find fine their experience. The masses just want it to work.
And that's fine, let the prebiotic soup be the starting point. You learn the landscape make frens and find where your tribes are, you can worry about how to configure your relays after, especially if you're following others who have already done it.
Essentially, yes. Some methods will work for some people and other different methods will work for others. As long as we have choices and more options for more technical users, but also don't forget about newbies, I think we'll be okay.
i think that creating a "free tier" scheme for reqs that ONLY include a specific npub that is a paid member is one element of making distributed relay data storage more practical another is that the relays need to have garbage collection, so only specialist archivists keep everything and lower the cost of most usage (and archivists can sell that acceses to paid relay operators so they can fetch it and cache it in their GC'd data stores) - and yes, also, my GC implementation is not selective about anything except frequency of access but more advanced GC mark configuration could include things like preferring to purge non-paid member events that have also old parent nodes to be cut off before cutting out the paid relay old events, and so on one of the things i want to do with my work on replicatr is making a "layer 2" event store that you configure with other relays that you share with, so they can distribute events horizontally to shard out storage for users outside of that, tools that let users know what relays are best for getting everyone on their follows both their events and them seeing them would be really useful as well