Note: "Relay agnostic." 😎
cloud fodder's avatar cloud fodder
Proud to announce, since developing on Cordn I've found and fixed 13 bugs in Kotlin-MLS, the library that all nostr MLS uses! Cordn is a relay-agnostic, multi-device supporting MLS client for nostr. It's got these cool coordinators, and all the features that MLS has. https://code.relay.tools/opensauce/staircase/-/releases/v0.1.15 https://zapstore.dev/studio/apps/tools.relay.staircase
View quoted note →

Replies (41)

99% of users will NEVER run a coordinator. Most people don't run relays. Why would they run something even MORE complicated 🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣
It's fine. I'm sure some users want centralization built into a decentralized protocol. It's the Primal argument. Some users prefer the trade off. Just be honest.
What are you even talking about? 🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣 I can be a clown too.
Gotta give people back what they dish out. If they can't take it, which they can't, that's not my fault. You don't get to shit on other people and then do the same thing and think you're better than them. It's childish and exhausting.
You don't get it. That's amazing. You want relay runners and devs to change how their function because you can't figure out how to make your app work while simultaneously trying to lie about how cordn is "centralized." To your own point, 99% of people won't change the requested setting. This necessarily means that WN is only going to work on a tiny fraction of relays. Tell me how that's not in real effect centralizing traffic? Could I be wrong about this? Sure. But if I'm not, you're only making a fool of yourself. I'm already an idiot, but I'm not that foolish.
What are you talking about? I don't want any of this. 🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣🀣 The guilt is making you say things that just aren't true. It's weird.
Every MLS member must apply the same "Commits" in the same order to keep the same keys, so the coordinator gives each group a fixed message order. It only stores and passes on sealed MLS bytes; it never holds any group keys.
I love my echo chamber. We're all googling at you guys. And you guys deserve it. You've been crapping on a lot of my friends for months. It's past time more people see you and your ilk for what they are. Thank you for your service! 🫑
That’s simply not true. First of all, anyone is free to run a coordinator, even on a phone or in a browser tab! no ip, no networking required... much easier than running a public relay if you ask me... Also, no events are stored on any relays, so users are truly sovereign, and this also comes with great privacy advantages. No external observer can know anything, and there’s no collect now decrypt later. The fact that the only things that touch relays are ephemeral events also reduces attack vectors by a lot. But in any case, you guys, all of you who claim that cordn is centralized and use that to diminish it, have a point: one coordinator at a time is the only way to ensure things work. But you are about to lose even that point. We are already working on multi coordinator arrangements, so there won’t be any single points of failure. Everyone in a community can run their own coordinator (on their phone if they want) and all of them will ensure that comms can continue even if some are down. On the other hand, your argument doesn’t have much value when Concord itself needs special relays to work as expected and mitigate spam, which, from my pov, is a centralization vector.
That is great news. Once you don't have to have one single point of failure, a coordinator, I will stop saying it has a centralized feature. I look forward to multi-coordinator support! Let me know and I'll try it out then? Concord doesn't need special relays? I use it with a wide range of them from WoT-Relay to Strfry to Ditto relay. All work well. I did run a group with Haven and had issues there but that makes sense since Haven isn't supposed to be a public relay.
I mean, you could stop saying it right now, since it is not. There is no single coordinator run by a company or nothing like that, and it's also a protocol ya know, sandwich made a client, now cloud is making his own, all of them interoperable, no obligatory coordinator anywhere. But yea, hardening and federation are important points and they are already in the works. And yea, concord so far inverts the nip-17 expectations, specifically this point . If you guys change that part of the spec I will shut up, but so far I think you still using the pubkey of the channel as author. So relays need to choose, be compliant with nip-17 or concord. I buy that is not at hard measure and any plain relay will work, thats why I said 'work as expected' in my comment, not just that doesn't work in regular relays.
OK... So suppose I have a MUC and a coordinator, what happens to that chat if the coordinator goes down or blacklists my IP or npub?
It's still an argument for centralization. It's the same argument for relays. I think NIP-65 resolved that. I think your multi-coordinator will resolve it too!
How is it centralized? I can run my own. Anyone can run their own. That's not centralized. That's distributed and decentralized, especially after the multi-coordinator stuff goes through. If you consider me centralized, then sure. If you consider nostr relays centralized, sure. I'm laughing at Derek. He's turned into a bafoon and is a lot less lovable than he used to be.
Yes. I did. It doesn't matter of you don't believe there is one. It exists. Annoyingly. Do you not use any repos that are hosted on GitHub?
Well, I'm just now learning about this, but it appears to me whoever controls the coordinator for a group can kill the group. Not so with nostr relays. I can run my own mumble server, therefore its decentralized? No. Thats not what "decentralized" means. If the coordinator can be swapped out at any time without fucking up the group, it's decentralized. Otherwise it isnt. Relays can be swapped out any time without messing up anything for the user, you can have redundancy in relays. Is that true for cordn coordinators? If not, its centralized. Simple as.
Can you have redundant coordinators for a room? Like say, one goes down, blocks users, etc and another picks up where the first one left off without any impact to the chat or users? Or is it a pick one type deal?
Sure, but it is my group. Of course I can kill it. That doesn't make it any more or less decentralized. None of the groups are permissionless, either. You have to have a creator of a group. They don't just pop into existence on their own. So.... I don't get the complaint. If I invite you to a party at my house, I get to control thy guest list, unless I allow other guests to bring their friends. But I'm still at my place. I'm not in a commie block house, assigned by a central administration. Does that make any more sense?
Yes, but if you have a party at *my* house, you can send everyone home or I can do it without your permission. You assume that the common architecture of this is going to involve a room creator running a coordinator. That is most certainly not what the network architecture is going to look like.
Yeah. But that's not the same thing as "decentralized." If and when you can make these coordinators redundant, add and remove them at will, without borking groups, the same as we can with relays, it will be. As of right now it is not.
↑