at least we're not on truth social that he built. one of the worst most failing social media platforms out there.
they wouldn't even be given any choice at first, outbox should handle it all for them. the client would look for the relay list of the npub they're trying to follow, in a predefined set (including nip65 specialized relays), which should be as large as possible.
once the relay list is retrieved, thats a bunch of relays to explore, and in those relays, they might find hundreds of relay hints in events. thats how the magic happens, unless they're exploring nip70 dedicated relays.
now if their point of entry is a relay, it's either:
- amazing, a regular relay that relays events as it should
- terrible, that relay is nip70 only, all the events are exclusive to it, no other relay hint can be found
this is a completely different scenario than what has been talked about for these NIPs.
here the data probably does not hold any value to the point where people would broadcast the events, and nip63 doesnt apply, only nip70. in that case it makes sense, but the user needs to know that they could be rug pulled anytime by that google drive and dropbox, if they were to not care about the tag anymore.
it would only be perfect in a scenario where the user owns both relays.
so if that user wants peace of mind, i wouldn't recommend going with nostr. it unfortunately isn't a solution in every scenario.
you know better than i do how nostr is, among a few other things, a solution to censorship, definitely not a solution to everything.
non-centralizing defaults come with outbox to begin with. however the user discovered nostr already gives a point of entry into the ecosystem, that could be following someone or connecting to a relay.
and for obvious reasons, your third option is objectively the best, users need to have a basic idea of what goes on behind the UI so that they can make conscious choices.
i agree with you that it gets really confusing, and thus the reason why this space needs more UX designers which are good at dealing with decentralized tools.
I made a relay that charged for access and started working on a framework for making custom relays with arbitrary policies in early 2022: https://github.com/fiatjaf/expensive-relay
I remember using the phrase "relays must have personalities" early on too, and saying that Nostr finally realized the Mastodon vision of having communities form around servers (as Mastodon failed spectacularly on that).
I also remember getting angry at the hundreds of people who misunderstood Nostr as some kind of neutral data layer for cryptographic keys (generally the same people who are happy to just hardcode 4 relays in their apps and call it done), or people who tried to do spam prevention using any techniques that were not based on knowing some relays to be free of spam and others not, I wrote this, for example, as an early attempt to nudge the conversation in the right direction: nostr:naddr1qqyrxe33xqmxgve3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cywwjvq.
I don't know why you think this is bloat. It's the opposite of bloat. I hate bloat, but relays with personalities are the only way to avoid bloat. Without relays doing custom things to prevent spam, curate content and acquire reputation we're left with megalomaniac specs for doing the same thing on the client side in a much less efficient and less personalized way (as you can see from all the bizarre specs we've seen being proposed throughout the years).
By the way, DVMs are a clear example of what happens when you start to treat Nostr as a form of neutral data layer. DMs too, probably, then in the evolution of the DM spec you see how things went, with overcomplication on the client-side in order to try to achieve some ideal privacy that in the end is only still guaranteed by the relay (NIP-17) or Marmot, which requires no comment.
Anyway: if you don't think relays should be different, then how do you account for incentives?, i.e. should every relay just accept any note from anyone or how are they supposed to filter content?
theres a fine line between relays having a personality/filtering/curating content and poorly attempting to make events exclusive to them.
the idea of restricted access to events on nostr is a joke, thats just not compatible with the protocol. those NIPs are useless.
there are and there should be a variety of relays, because of the need for incentives but also because some stuff just cannot be done client-side.
now something i wish people looked more into is user or local communities owned relays - which are closer to the user - that's an opportunity to get done whatever is too heavy to do on clients there, making sure users have full control over it.
even the outbox model would scale better that way, having clients fetch events from a home relay.
Current status of Project Zymogen, the Radicle-based P2P GitHub alternative -
We've found a dev, Andrew K, working on a related project: crad, a C implementation of the Radicle CLI / node. He's been trying to modify the crad project plans to fit my proposal.
Today, Andrew K announced that the crad CLI has achieved some essential functions. The repo is hosted on the OG Radicle.
There have been no progress updates from pollghoul, the other dev that was going to give this project a try. They had said they preferred to work alone, so they might be waiting to see how Andrew K's work goes.
Current funding: 6.268ɱ (approx. 2,900,000 sats / 18,000 doggie coins)
https://app.radicle.xyz/nodes/iris.radicle.xyz/rad:z2ydYmUCJvDfNFTVTpEbQmm55EPt1
something pretty interesting about radicle: they claim to adopt a peer to peer archiecture that's based on a mix of secure scuttlebutt (very similar to nostr) and bitcoin lightning network
NIP 70 and NIP 68 are pointless possibilities, or useless proposals, whatever you want to call it. for the reason that they don't make sense with the 'core' protocol. get it now?
he didnt mean that literally, nostr clients talk to relays and relays talk back to clients. interoperability is actually achieved when the data back and forth with relays can be created/interacted with from different types of clients, each specialized in different nips
exactly. and a paywall fundamentally changes 'who has access and why' from a censorship resistant protocol to a gatekept permissioned one, which simply goes against that principle
in real life a simple tag won't make any difference
its like printing something on paper and believing that just because you stamped it, people won't photocopy that paper. that is absurd. if the content on that paper is valuable then it's safe to assume people WILL keep a copy of it. that's the reason why scanners don't let you scan money
nostr makes the whole process infinitely easier, its a matter of unchecking a box on your relay settings, and broadcasting the event with a single click
comparing paper with nostr... i hope you're joking.
look im not trying to get philosophical here. its very simple, nostr has data portability designed at its very core, copying events, sharing and broadcasting them is what happens all day long on all relays
relays are meant to relay events, not poorly attempt to gatekeep them
its all up to the user if they want to take the "-" tag into account or not. if piracy was that easy, it wouldnt even be called piracy at that point
and if you really still think it could work, in a dystopia where everyone respects that tag, look, companies could start using it in a detrimental way for users. say google for nostr, requiring auth on every connection, then we're right back to centralized systems
This is a fundamental misunderstanding of Nostr.
nostr:nevent1qqsv036tlptg0t3mn9jhzzhpxfk4jgpgpghrn7gpxpjphmhhje3lcjq7dah2r
not at all, you're misunderstanding this.
this protocol makes data FREE. technically speaking nip70 and that new one are pointless, those 'protections' will be ignored in the real world
i think its actually kind of sad, when we have the opportunity to embrace data and information being completely free, you all go ahead and pretend like there can be implementations against that
i do agree with other takes you've posted before but the belief we can restrict access to content on nostr is simply not true
nostr:nprofile1qqsgzu4eypfy0h07nxmcxvs8stgrztarqksen7etaz37v437yz60pcspzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59uzkvpwz nostr:nprofile1qqsyy2wzruqsr27rhfzjx0shd6t4l20xwxa33fnj900hwf46y4z9l7gppemhxue69uhkummn9ekx7mp0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tc4w0e7l
centralization = headaches every single day for everyone
decentralization = "a burden on the dev"
lets please not ever consider going down the centralized path🤝
way better to figure it all out from the start in development rather than production
the UI and UX of nostr apps are currently the exact same ones from legacy social media, theres no improvement whatsoever, the exact same manipulative mechanisms are copied 100%
the nostr ecosystem shouldnt be a mere alternative to legacy social media, it should be different and way more diverse, we should have a lot more to pick from.
feels like there are about 10 maintained reliable clients right now and half of them are web based apps...
if things keep going the way they are, thats going to happen 100%
that wont change until people quit using nostr as an alternative to the garbage social media world
hey nostr:nprofile1qqsgzu4eypfy0h07nxmcxvs8stgrztarqksen7etaz37v437yz60pcspzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59uzkvpwz nostr:nprofile1qqsyy2wzruqsr27rhfzjx0shd6t4l20xwxa33fnj900hwf46y4z9l7gppemhxue69uhkummn9ekx7mp0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tc4w0e7l i've been seeing all the progress yall are making with frostr and was wondering if you are planning on advertising what's being worked on to nostr users?
it seems very promising but i don't see much talk about it which is a shame. theres also a few things i don't quite get.
how does this protocol protect shares that have not been compromised in a scenario where an attacker would have control over a share ? wouldn't the compromised device allow for a request to get something signed from other devices/shares and succesfully get it back?
i think i saw theres a way to make it so that only certain shares can make requests to others or something along these lines?
a detailed explanation on how to properly and securely adopt frostr for one's keys on that regard would probably be useful to new users.
fortunately 99% of people don't have "anything to hide" 😂
ótimas medidas para que tenha ainda mais manipulação nas eleções
he might just be getting a little desperate over nostr not taking off. hopefully he'll learn that patience is key. on another note, thank you for your work with the outbox model, im sure it gives a lot of people hope and will be a major upgrade to amethyst.
idk if this is already a thing, but perhaps a new NIP for claiming an event could work? or a series of events based on OTS signed events on them. then clients could fetch all the appropriate ones for a given profile?
cc nostr:nprofile1qqsy67zzq5tc9cxnl6crf52s4hptdwhyaca5j7r8jwll535tdadedvcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3qamnwvaz7tmwdaehgu3wd3skueqpzpmhxue69uhkummnw3ezuamfdejs2sh6m6
this is something you could be interested in, for scheduling notes
i hear you, but rn when people don't like what they have, they already go out of their way to "rebuild" their algorithm by liking or viewing different types of content on purpose.
(i think a lot feel like they can control it to an extent)
and on the technical side, it seems that it would be so much harder to have algorithms on nostr anywhere close to how efficient the big tech ones are.
so i do find it interesting that we're looking for better algorithms and more choice, but in the long run is it actually worth it or are we wasting our time?
imo the outbox model is the future of nostr, and algorithms do not like that model. nostr does not thrive with algorithms.