Oh look we’re reinventing what made the Fediverse trash: Making data portability hard by tying things to relays specifically.
Opt out of NIP-29. nostr:note177uxm34pu4zgpcun5ezar966cm7uakaqajr62e9hxd2sutuzgmvsls8dck
Discussion
mostly agree, but nip-29 could have some niche use, like private groups where data portability is not a problem cause theres no data intended to be ported elsewhere anyway.
been looking at some implementations of the nip-29 but i haven't really read it
to be honest, i don't like the way it works, and i think that before we run off and do complicated shit we should do it simpler, this is what my nip-79 nostr relay chat is for... and it shifts persistence to the "client" side as well, the relay is only a rendezvous/tunnel
what's nip-79?
NIP-29 is redundant clutter + fediverse all over.
Which is exactly why I never opted in in the first place.
That said, I still need something reliable, decentralized that makes communities work AND be interoperable.
I don't find anything better, simpler, that works on everything we have now and allows me to cater apps to niche, overlapping communities.
Big difference in running a Fediverse relay and running a Nostr relay for yourself and your 15 frens to chat.
Reread my note pls
I'm for a community chat being tied to specific relays. I see the problem with them always only being tied to only one relay.
Prevents using redundancy and scaling to secure the data and services, and means that you can't use relays to tier or overlap data and services.
🤔
Yeah. Tying it to certain relays is fine. Only and only if you can move relays
Agree.
Then I need Communities to be more like npubs than relays, in the end.
With their own keypair, that lets the community admins publish wherever people should look for events / media / etc...
But NIP-29 groups already have an ID.
It's
"christpill.nostr1.com'3a2873jk9279"
Couldn't we just allow for n number of hosts to preface the identifier?
like "christpill.nostr1.com'biblestr.gitcitadel.com'3a2873jk9279"
An ID that:
- isn't unique
- you can't sign anything with
- all relays involved would have to agree upon (namespace)
- only is a solution for relays (not media serving, etc..)
- still only lessens the DNS vulnerabilty
no
Isn't that what we had before? The communities I started under the old NIP had a relay list. It somehow didn't work.
Anybody? How is this not just a return to the previous community structure?
Yes, it's similar.
Important differences:
1) NIP-72 didn't have chat, lol 😜, which would have made it a ton more active from the start
2) it still forces creators into the false choice of publishing in one niche vs in the fEeD. And besides chat, they'll almost always choose the feed
3) in the way apps handled it ONLY the root posts were somewhat constrained to the community
4) you can't edit that a-tag away later (or add other communities that fit your target audience)
5) active approval is required. The signing of an event by a moderator, and the delay that comes with that, is a huge barrier.
6) there was no interop between relays and this spec, so admins could not just piut a relay behind their community that followed the moderation/price lists they defined in the Kind:34550 community definition
I'm still not sure if the community needs its own keypair or whether just defining moderators is fine.
In the end there is 1 owner
it's not really a community if ownership is that concentrated, that's why i'm arguing for the idea of building a design that gives every participant some degree of control over their experience
without being open enough for emergent things to happen it just isn't going to have the ability to grow at all, in the long term
like, i made this gophers chat on matrix, but i didn't do it for me, because most of you all others are either still kinda skeptical or mainly just not that experienced or knowledgeable and actually my posture on it is i'm here to help you all build on what you have and make it useful, and help you solve problems
so i don't want to have very much control at all, it's even better when enough people get involved and they start to be able to do that for each other as well
the same thing would apply for me running a relay to support connecting a community together... i only care about controlling it in as far as it doesn't become controlled by hostile entities
having to "sign up" is friction i don't see having any benefit for promoting social harmony and productive collaboration
my biggest problem with nip-29 apart from its excessive complexity is the fact that it doesn't lend itself to scaling to join multiple small relays to provide redundancy, this is why in my proposed nip-79 "nostr relay chat" one of the first things it attends to is how to wrap messages so they can be broadcast across to other members of a relay group
https://github.com/mleku/nips/blob/master/79.md
nip-29, as nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj is pointing out, binds the messages to only be valid and this has problems with DNS being then also tied to it
nip-79 makes no prescriptions about relays storing the data, it's my intention that clients like the IRC model of chanserv will cache messages and deliver them to users to enable async messaging
That's true. Can't use multi-relay architecture. That's a problem. We also have two parallel/mirrored community relays.
For my use case:
Would it then be better to have communities be keys?
So that they can have a redundant relay (and even media server) set up?
I guess there needs to be some way to combine community relays in a group. Maybe. 🤔
Like, the christpill.nostr1.com and the biblestr.gitcitadel.com relay could be a relay group for #Biblestr.
i personally am not that hot on moderation of lists either, i think people can do that by themselves, if the UI makes muting simple and actually working
really really don't like what i consider to be the "reddit" redefinition of blocking into "muting" at all, or the practise of hiders tempting you to click on them like a big red button labeled "don't press me" it's inflammatory and unhelpful... i want to see my mute list, i click on my configuration, i don't want it to be part of the main interface
first you have a relay defined access control list enforced with nip-42 auth, and then you also can revoke access as well as specifically block npubs that may be included as "guest" members due to one or several of the first-level whitelisted users, this is the "infiltration" problem that is often used in open communities, it can be stopped by either blocking one or two stray (blacklisting) or if several of the users are falling for their bullshit, they can just be "nope, cancel, money back, here you are now fuck off"
the thing is that these rigid, hierarchic style of access controls like defined for nip-29 are prone to being taken over by psycho bitchez who want to lord over their little cult den and this is something that we need to give the common pleb user some power to influence, and by normalizing blocking people and a the chatroom deciding to collectively ignore some asshat who is trying to infiltrate a group the onus on the relay owners is less and this also makes it easier to join several relays together that may have some overlap but not complete overlap of membership
at the centre of my philosophy about this is that the more power you put back in the hands of the user, the less levers you give to toxic bitchez who just want to be the authoritaah in a non-hierarchic group, and that's not ok with me, and i don't think it helps by letting me decide that, it's better if there can be a progressive escalation of response that comes from the individuals instead of having to travel up through centralised networks
The whole point of groups is to limit who can be in the group and/or what they can post there.
yes, limit, not define
and it's a dumb idea to put that power entirely in the hands of the moderators, because that's centralization and an easy attack point
Well, we moderate by determining who is allowed to use the relays. If someone wants to use their mutes in addition to that, then that is fine by me, but the conversations might become disjointed and he'd probably end up getting muted back, a la Karnage, if he was annoying enough about it.
yeah, the idea is that if someone is unliked by the whole group they all end up muting this asshat
and if it's something that only bugs a minority, they leave, stop subscribing to the chat of that group
the role of the relay owner (and there can be many) is to control access at the edge of that process, so, in theory, you can have like 2 relays joined and many overlapping clients passing messages back and forth between users connected to each side
but it could happen that on one relay, you have faction A, and another relay, faction B and they can thus peacefully decide to be separated if the relay owner is good about this and realises that it's best for everyone to let the cult drones have their #hashtag on one side and the rest of us on the other, you see what i mean?
this is a dynamic process and this is why ... and it makes me sad that i have to harp on about this but really, the modern kids have been brainwashed by modern social apps to have this belief that moderation is some magic wand that just happens and they don't realise it's done for the benefit of advertisers and spook agencies involved in mass manipulation campaigns
i don't expect this to be grasped instantly by people, but it's also going to take me a little time to build it out, and my requirement that the async features not depend on relay event storage is part of this, because other than controlling the ability to send messages into the relay i don't want the relay owner to have any more control, i want the channels that people create to otherwise be owned by the people who are in them, by association, by the name of the thing
proprietary association of names with group membership just results in a proliferation of social islands, i want to help promote the idea of those boundaries being permeable
I also think any group that is based on WoT or follows-of-follows will quickly turn into a shitshow because a lot of people have follow lists full of crazies, spam, scammers, and porn. Like, look at the follow lists. Look at the feed of the bigger WoT relays. Or, rather, don't. 🙈
They always degrade because follows are such a cheap signal.
Also, for example, a Christian following an atheist is common, but those atheists shouldn't be able to overun a Bible study group. That would defeat the purpose of having the group. You'd have to throw all of the Christians out who follow the atheists, to get rid of the atheists, but that's punishing someone for having a diverse set of friends, which is not so great.
I may follow men, but it doesn't mean I want them all invited to my pregnancy group. People who are carnivores don't make for fitting members of a vegan group. And so on. Not that they might not _individually_ be worth inviting, but not a blank invitation.
Making everything about follows destroys the use cases for almost everything.
the idea is that the relay operator has an incentive to combat this kind of infiltration behaviour by explicitly excluding people who are actively infiltrating and poisoning a group
but at the same time it can even still be possible that another relay operator, even connected in a community relay group, may allow them there and they can have their empty chat that nobody sees their messages because their npub is persona non grata in the place where the users of that chatroom actually congregate, and that's all fine, maybe relay owner of the places where they don't bother to handle this stuff is not so popular with this group but maybe they retain their position because of other groups that are not divided liek this
it's not all or nothing, that's my point, and the idea that users should not have an active role in this is also something i think is unproductive because we are not a faceless corporation selling our users' data to advertisers
also, maybe you can see how if we make it easy for members to run the nodes that they can be active in both the social cohesion side of things, as well as the defenders of the group... so if we are making a chat about bible readings, and we get a constant problem of attacks from other users of the relay who follow these people, we can run our own node in the network, and block the messages of these users by either blacklisting them or removing the follows that follow these assclowns
i think that it should be pointed out that what i'm suggesting is also the Christian Way of doing things - to gently push back, and then if need be gosh darnit put up a fence
and i want to promote the idea of larger groups of relays cooperating together, so there is points of control that everyone can exert a small pressure as they see fit and when it is obvious there has to be a schism, so be it, put up the fence, just give people the tools
Okay, but I need a construct with one community-member list for multiple relays and I want to define the relays.
well you have your nip-29 and nip-17 to work with
i prefer the idea of creating a playground and then just applying force to exclude bad behaviour, not people
I'd rather just exclude the people. Christians aren't punching bags.
yes but you make stuff like what happened with highperfocused and cloudfodder in the gopher chat less likely to happen, i just made that channel to get people talking to each other about building go stuff, and cloudfodder jumped in and helped out as well as me
i think there is a lot of benefit in this soft approach
probably it helps that i'm in the process of house training a cat, this little guy does NOT like force, at all, every moment i am violent i am losing his trust, and even, like just before, his big dady, pretty sure he's daddy, came around to visit, the neighbour cat, and i carefully intervened so that these two didn't get too close to each other and mochi had his safe place in my place and the other cat didn't tread on me or my pet
doesn't take force to achieve this, more, just vigilance and readiness
You can have public access or high signal, but rarely both for very long. Groups have the same dynamic as relays. They don't need moderation, so long as they stay small.
yep, that's what i mean... joining is just opening the client and adding the relay
moderation is minimally required for those edge cases of infiltration behaviour
allowing these groups to cross to multiple relays is important especially for the case of small, affinity groups, whose infrastructure may not be expensive and reliable, in fact, in our case, we may even be running fully customised things on it which adds to the risk of downtime, so building in the ability to add redundancy to it by multiple members of the community running relays and they may not necessarily participate even in the same channels on them overmuch but have other associations with each other that are of a lesser depth, but in this way they back each other up
That isn't really a community, tho. It's more an association or cluster.
Community is about being in communion.
NIP-17 is garbage
possibly yes. I had recommended this to nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7208x3z in the past, where a community can run an 'agent' somewhere (a bot, with the community root key).
The reason that devs keep wanting to put logic directly into the relay is that nostr has no official spec for moderation of a relay and the nostr world is very opposed to talking about moderation or making it easy, so it is a green field.
As a relay operations team (could be a person, could be a team): The requirement of moderating a relay will not be going away.
And then, we have communities that *also need the exact same same types of moderation capability.
So, this is why I believe nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9uq3xamnwvaz7tmhda6zuat50phjummwv5hsx7c9z9 concluded in nip29 it would be simpler architecture wise, to combine these. Which does sacrifice the separation of the two and removes the ability of a community to use a relay that is multi-purpose. I'm unsure how 0x is managing to have multiple communities on their single relay, as my understanding is that the operator of that relay is also the admin for the community (the relay has the private key).
The basic structure of moderation I employ on relay.tools is for example: Relay is owned by a root key, this is 'super admin level' access to the relay settings. The next level of access is moderator level which can do anything except for change moderators and change relay profile/description. Then there are the relay user level which is the normal join/post/read. This could be refined but its what i started with.
Say I'm a relay operator and i want to contribute to a community by mirroring the content, if the group allows my relay into the list, ideally i should not need the community admin key for this..
Communities will likely want a similar tiered access scheme and it will *have to combine with the relay level access scheme at some point if the community wants to delete notes that they do not have a key for. This is all a lot to think about.
Enjoy 🌝
It would not be hard to adapt keys to relays in a transport-agnostic way. Just add a new event kind 3xxxx which means "I am a relay" with tags declaring relay address under different transport (wss, onion, etc).
> The reason that devs keep wanting to put logic directly into the relay is that nostr has no official spec for moderation of a relay and the nostr world is very opposed to talking about moderation or making it easy, so it is a green field.
This misses the point for me. Relays largely already have everything they need to do moderation (nip 56, auth, and deleting stuff), which means the best form of moderation is going to be implicit on the protocol level, explicit on the human level.
But I agree that the needs of a community for policy enforcement neatly match those of any kind of relay.
Relay-side moderation also has the problem it interferes negatively with caches like nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s's NostrDB
nip56 was created to get damus into the app store. not a lot of thought was put into that.
what is missing is fine grain control. clients decided to send reports to all relays (flawed). imo to really manage a relay you are purposefully telling it what to do, and from the convenience of one key that you are reading the relay from. if you want to delete offtopic or etc from your relay, you do not care about other relays nor do you want to broadcast your actions globally for all time.
For end users and moderators, I think nip 56 is perfect, since reporting should be declarative rather than imperative. For administrators who actually want to unambiguously delete stuff, NIP 86 is probably the right way.
> Just add a new event kind 3xxxx which means "I am a relay" with tags declaring relay address under different transport (wss, onion, etc).
Is there a serious case against this? Because that's exactly what the noob in me would do. Leaving the option open to also specify the media servers that Community uses.
> Relays largely already have everything they need to do moderation
Yup, they might miss just a few things to make Communities work, but that doesn't mean we need copy (and add unnecessary complexity) to the whole relay spec in something like NIP-29, just to add these.
It seems reasonable enough to me, but we'd have to propose it and see what others think. And yeah, communities do need other things, at least granular permissions for sub-groups, but the starting point IMO should be relays as groups
Number one problem is binding them to DNS more important to decouple that than talk about adding features.
there is no expectation of censorship resistance in a private setting like closed communities. I don't see a problem with nip-29. I definitely want to censor people from my private communities.
NIP-29 is specifically designed to make groups copiable.
Last time I heard from nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q he hated NIP-29 for that.
I dislike NIP-29 because it reinvents what relays already are, because it ignores the potential of content being interoperable in between overlapping communities and because plays Telegram copy-cat with features that don't fit Nostr's building blocks.
The fact that you can copy groups is, on the other hand, one of the things I would like about it. But as I understand, the (non-editable) h-tag being part of all the content doesn't make that easy neither.