how would this work for people who aren't administering a relay whitelist tho?
Discussion
Pulling from Communities that they (publicly or privately) labeled
Yeah, or just, like, use some other list.
Making this The God List has lead to developers designing all of their apps around it and destroying the protocol's biggest design advantage: relays.
other lists have to be supported by the client, that's a major problem.
also, it doesn't have to be public, mute lists have a private section now too.
the main problem really is just that primal pretty much administers the God List and they are extremely biased about who gets on it. the real challenge is a good client to onboard people to. coracle probably could do the job, and even he made it so it can be whitelabeled. the other thing is outreach to other social networks where there might be interest.
True.
I think listing people (instead of communities) and pulling EVERYTHING from said people is still an issue, even if you take away the Follow list as the one-and-only.
Community relays :rocketship:
distributed communities too, with lists created by community administrators.
Shared lists. Yeah, I could add that. Using other people's lists.
But lists aren't really an alternative to relays. They sort of miss the point of the exercise.
routing on networks uses lists, it's lists all the way down.
Yes, a router uses lists, but it isn't a list.
Abandoning control of the hardware layer seems like a net-loss.
if the data needs to be public, it needs to be a list. this is what ip ranges are about. this doesn't translate to keys at all, because they are high entropy unlike address ranges.
the hardware layer has to sacrifice some privacy to enable this.
cryptographic identities for network nodes requires intensive configuration. i'm doing it right now creating a 4 node 6 path wireguard mesh right now
A relay community membership list doesn't need to be public.
i've been thinking about this and it can be a privileged event that only the relay and the author can read, and using bloom filters to designate the list so even if the list is leaked you can only check it one by one to see which npubs are included
Interesting feature, that latter one ✍️
My current exercise is figuring out how to let badge-holders hand out badges.
As in, only if you have the badge can you award that badge to others.
Want to use that as an "Invite link scheme" option for Communities.
Community key should be able to break a chain (tree branch) gone awry.
The Communities can already specify badges as write-access condtions for any of their content types. So this would pair really well with that.
"Just" need to rewrite the badge spec with this (plus make the award event a Relationship event).
you should read up on cryptosystems for this kind of thing. it can be done, i think. it's about key derivation trees
there is the other solution for this too, key registries. but this requires some kind of scheme for non-cryptographic identities. nip-05 might be a candidate for linking things together, i'm just spitballing
Thanks!
- automating badge rejection at the relay level
- apps verifying the tree up to 2-3 levels
I'm wondering if "just" a combo in that vain could be enough and avoid cryptography schemes.
someone has raised an issue about mute lists and it occurs to me that bloom filters could replace explicit lists. more compact data-wise and more obscure in that you can't know if you are on it without testing the filter on your key.
a replaceable event containing a bloom filter could be used for the case you describe.
i'm also going to ponder this idea for a secondary mechanism for defining mute lists on #orly because it is possible to define this event kind as privileged so only the relay can read it as well as the author
Yeah, I am across bloom-filters several times the last week's too.
Still need to grasp its application more to cases like this.
well, i think that it's not really useful for one-off stuff like relay configurations but for distributing them it might make sense, as it saves some on bandwidth. but i'm not seeing a strong case for this. events are not that big in data size, especially not when encoded as raw binary. typically follow lists are like 1/4 or less the size of the json
Also, end the situation that there is anyone on Nostr without a local relay.
That, right there, is the core problem.
And we are working hard to solve it.
local relays definitely are a thing. especially they should have little crons that fetch from other relays. and also there is a great need for inbound routing so users can also have their frens write straight to their relay.
some of these obstacles are systemic issues on the internet that bias against p2p, and most p2p protocols are quite deficient, but largely because of the restriction of routing.
I'm focused on everyone having a local, personal relay that aggregates across a filter, and background-syncs with their client, and remote community relays, and some big search relays.
And the local relays on different devices talk to each other over Bluetooth, WIFI, or remote relays.
I find lists interesting for bookmarks and categorizing npubs, but labels and badges might do that better, so I'm implementing both.
Labels and badges, yuuuussss!
it reminds me, that would be a neat thing, a service you pay a little rent like $2/month and your personal local relay has a custom wireguard style VPN client that uses your nsec for its encryption. i'm pretty sure p256 keys at least (secp256r1) already can be used and 99.99999% of valid secret keys for secp256k1 are valid for p256. this would simplify configuration a lot. you configure the relay with your nsec and the VPN endpoint and you get a username.example.com subdomain.
i could build something like this to add to realy in a matter of a week or less. in fact, i already have a http reverse proxy that could be extended to add a user database that fetches from the service's relays to configure npub->name using nip-05 and that username would also be your subdomain. just probably need to have round-robin DNS to run multiple endpoints and configure the multiple endpoints in the relay and it would switch to another one if it couldn't reach the first option.
if only i had the resources to build this. i do hope i don't get stuck without a serious job prospect by the end of next month, i'm gonna be in a pickle.
That was supposed to be 🫂, sorry. Emoji fat-fingered typo.
Didn't nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl implement something like that?
he did, but i wouldn't want to run a javascript based relay when i have my own perfectly good relay. plus i already have a customised reverse proxy so a lot of the parts required already exist, just needs a bit of glue to join it together and make it easy to install and use. it could directly use your nostr identity also, to make things even simpler. some kind of 30k series configuration kind that is marked privileged that the relays on the connectivity services use to set and read your configuration and subscription status and whatnot.
it's probably a month's work for me to do it. i'm gonna think about it, since i can't be job hunting all day long since there isn't even that many realistic job options for me anyway.