Relays are servers too ¯\_(ツ)_/¯

but you don't need to run one.

The architecture of decentralized communities like Soapbox represents a genuinely astute response to escalating surveillance trends – a recognition of value far beyond simple connectivity.

Well, someone needs to do it, and if you are relying on someone else infra (specially when there is no mandatory redundancy / coherence between relays) you better be prepared for that infra to disappear or be hostile

sure, which is why you can use multiple relays, just like regular nostr. this is why i've always disliked NIP-29. i don't like single points of failure.

Se for realmente anônimo isso revoluciona a comunicação. Congrats.

That’s my, in my opinion, Concord supersedes NIP-29, same features, fully encrypted, fully decentralised.

absolutely. we're in the same camp. though i will say that NIP-29 has it's use cases. i.e. if you're on a company VPN or segregated network, you don't need encrypted company chats because no one can get to said network besides the company users anyway.

You could still do this with Concord too! Run your own company relay, AUTH whitelist npubs (team), and run a team Concord chat on that relay, you'd be better protected as a company, if your relay is compromised, your chats are still not, on-prem is further secured with Concord.

sure. perhaps then i should amend my statement that you don't have to run a relay with Concord, but if you want to, you're given that choice, whereas with NIP-29 communities, you have to run one, and there's no way around that requirement.

When I try to create a group I get "no relay accepted the change"

I assume you're trying offline Amber. I haven't used it and given all of the issues we had I assume it's related to that. I'll test later tonight.

where can I contribute with feedback and feature requests?

Wow, is this a post where you actually give an honest overview of the security advantages your app can offer, or are you lying about these too? Either way, how long until you go back to lying about shit like "end to end encryption?" (This bitch I'm replying to probably won't answer, he's muted me in the past)

I'd say your best bet is to join the conversation in our Soapbox Community on Armada itself and drop the feedback and feature requests in the Armada channel.

Armada

Armada

A sovereign harbor on the open relays — NIP-29 servers, channels, and voice. Your keys, your fleet.

Yes, but I also did dm you on there and it seems like it succeeded fyi

i did get it, yes.

done!

Well, kindly pushing back on the "just like regular nostr" part. I've been reading through the spec and the Armada codebase, and that part doesn't really hold up. Concord relays need a specific configuration, as far as I can tell. Concord reverses nip 59. A normal gift wrap has a random one-time author and the real recipient in the p-tag. Concord flips it: the author is a the stream key, and the p-tag is a random ephemeral key. Members read by the author, not by the p-tag. So it breaks on any relay doing the nip 59 "correct" thing, because nip 59 says relays SHOULD only serve kind 1059 to the marked recipient, and here nobody is the marked recipient. The spec admits it outright: "Communities must choose relays accordingly." Also, if someone uses relays that prune or just nuke their db, that breaks the whole authority layer (roles, bans, channels all ride on 1059), and deletion gets messy because every wrap is authored by the same shared stream key that every member holds: on generic relays that honor author-based deletion, anyone can delete any message, or all of them, just by sending deletion requests, which from my POV is a huge hole. In practice Armada runs on two default relays configured in the same way

Fair pushback, but at least anyone can make a concord compatible relay and the more popular this gets the more relays will adapt for it.

The architectural shift toward decentralized communities represents a surprisingly effective counterweight to escalating surveillance trends; it’s remarkable how quickly self-organizing protocols can emerge when genuine privacy is prioritized.

i'm totally ignorant of nip 59, but: "nip 59 says relays SHOULD only serve kind 1059 to the marked recipient" establishes trusted relays. trust is a mistake that gets you burned

It's just what the spec says, its not trust, just compliance with the protocol. An implementation doing something different is just not implementing the protocol

yes, but how would you ever know? compliance is discretionary

A protocol defines a contract that all implementations must follow. If an implementation deviates from that, it is either a non‑compliant (bad) implementation or an entirely different protocol. The “discretionary” aspect refers to enforcement: no external authority automatically guarantees compliance, so violations may go unchecked. When non‑compliance occurs, interoperability breaks

i'm not disagreeing on the fundamentals, but sending any event to anyone that asks doesn't break interop, just like retaining events when the spec says they should be dropped. if you rely on this behavior, someone will get burned

Yea, sure that's the same critique I had for nip-70 (protected events) since the beginning, but from my perspective, the key here is that if an implementation doesn't follow the spec is a bad implementation, and then we can discuss about sibyl attacks, but that's a different conversation.

i don't think it is. a good protocol is sybil resistant sure, the published source code can reveal it is doing the wrong thing. but you don't know what a relay is actually running, who is running it, who pwned it, or who captures bytes on the wire