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.
Discussion
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