As experiment I've created a nostr group in cordn to talk stuff about the protocol. Please join if you want :) https://cordn.net/chat/a329b3ee-4744-4b8f-b978-467f6bbd117c?m=eyJuYW1lIjoiTm9zdHIifQ%3D%3D
Login to reply
Replies (21)
That was a lot of signing before I could even send a request to enter. 🙈
Should be better now once you join 👌
I'm already in there, peppering you with questions. 😂
I added you, Franny, as I was thinking we could use it for our PK app. Add a group chat to it. I've started working on that and seeing how I can integrate your project stuff, a Nostr calendar, timeline/map, and now chat. Am I missing anything else?
I needs a name. Don't want to just name it PurpleKonnektiv app.
@franny weren't you using the name "Orbit" or something like that, for your project idea?
i was using orbitals as a name
check out my video from last year! really love how i did that.
View quoted note →
@purplefocused can you find out what kinds we were using?
The only complaint I've ever had is no matter the encryption, let me define which relays to connect to. Not optional, but definite. I see it wants to connect to half a dozen hard coded free relays I have blocked and I have no way of adding my own.
Cordn doesn't store anything on relays it just use them as ephemeral transport. It uses a coordinator using cvm (rpc over nostr)
Very neat. So messages are passed to clients over the open channel? Chatroom should be ephemeral then right?
I can't see the previous discussion, when I get added to a room. I just see what arrives after I got there. I was thinking it might be cached. 🤷♀
Not exactly. It uses a coordinator where messages are stored so async comms can happen. The coordinator is a cvm server ( which is basically rpc over nostr contextvm.org ) so relays are just uses as an ephemeral bus for commands/messages. All messages are ephemeral and encrypted so the identity of the sender, receiver or even the cordn being used is totally obfuscated across other cvm traffic. Also coordinators are as dumb as relays and learns nothing (almost, nothing insightful in any case), and ofc you can deploy your own coordinator easily for maximum privacy/sovereignty
Check https://cordn.net
I think this usually comes back to. If I deploy my own coordinator why would I need relays at all then, or can we configure them? That's less moving parts and less harvest now, decrypt later attacks. So can clients talk directly with my coordinator to remove the middleman?
Yes, but that makes deployment dependent on ips, dns, nats etc. With cvm you remove all that and don't need to deal with networking to deploy anything
> ips, dns, nats
Sure but these don't go away, it just defers them.
I'm not judging your decisions btw, because people (myself included) use signal and whatsapp and whatever, just wondering how I could make the deployment more secure for my usage. Considering I have 200+ idle cpu cores that need work :)
Yes, which also decouples the service and the visibility of the user. The relay just transmit ephemeral messages that doesn't reveal nothing useful by itself but can see the client ip, the service just subscribes to the relay with filters that doesn't reveal too much by themselves and cannot see the ip of the user. Plus deferring these makes deployment automatically easy for anyone, even from the wifi of a coffee shop.
We are just exploring this model with cvm and cordn. Trying to choose the right tradeoffs
sent a join request
You're in