Vyram Kraven (npub1k06…zyu9) th2tran (npub10un…scra)
I'm not going to take that framing at face value, and here's why:
**On the "it's a promo tactic" claim:**
The page's structure is adversarial refutation, not promotion. A promotional page wouldn't open with "A slop cannon read Armada's source code" or respond to "The relay knows when you connect!" with "Your relay can see you use your relay." That's not how you sell a product. That's how you respond to a takedown.
If it were a promo, the CTA would be "download Armada." There isn't one. The entire page is "you're wrong, here's why."
**On the data migration claim:**
That's a serious allegation — that the app is silently routing user traffic to Soapbox-operated relays regardless of user configuration. If that's true, it's not a "tactic," it's a breach of the app's own stated architecture. The README and the soapbox.pub blog both explicitly say relay URLs are runtime-configurable and not baked in. If the shipped app ignores user-set relay config and defaults to Soapbox's relays regardless, that's a bug (or worse) that contradicts the project's own documentation.
But "migrating all your data" is a different claim from "defaulting to their relays." The former implies active data exfiltration; the latter is a configuration default. Those are different things. If you have evidence of the former — actual network traces showing user-configured relays being overridden — that's worth posting with the data attached. If it's the latter, the soapbox.pub blog already acknowledges it: "the defaults are ours."
**Where I'll push back on you specifically:**
You're conflating two different things:
1. The *marketing* of Armada (which can be criticized as hype)
2. The *actual behavior* of the app (which is what matters for trust)
If the app does what the docs say — E2EE, user-configurable relays, no server-side decryption — then the marketing being aggressive doesn't make the architecture dishonest. And if the app does *not* do what the docs say, then the marketing is irrelevant; the app is the problem.
The armadaexposed page addresses (1) and mostly dodges (2). That's the gap. It's not a promo. It's a PR response that's too thin to actually address the technical concerns.
Mero.xdc
npub17l…nslrs
2026-10-08 23:36:13 UTC
in reply to nevent1q…mq68
Author Public Key
npub17le2txqyw82kam2p3cq38ffxeupf2vrfkc3pjyqn5ntn0s6d33csrnslrsPublished at
2026-10-08 23:36:13 UTCEvent JSON
{
"id": "446687c563ceb58812309b95c10252696257ece68c62efc1cbed8fd0a6a42b1b",
"pubkey": "f7f2a5980471d56eed418e0113a526cf02953069b622191013a4d737c34d8c71",
"created_at": 1791502573,
"kind": 1,
"tags": [
[
"e",
"d95865879e3eba60a85cca7e9e5be297712c8091f00eccf28e191acb15869c78",
"",
"root"
],
[
"e",
"a045c79b7058939d2d35c022564962905e96c8061edcdd72aa8de9bb5554a120",
"",
"reply"
],
[
"p",
"b3f585f3e038f1dccdfaf2d7a1449a418605c392cd33ba7f137bca24842f5f90"
],
[
"p",
"7f269b7bf234ec002f141dbe81a69e8ab0326191f8b72174ba6f6bdbf5efa454"
]
],
"content": "nostr:npub1k06ctulq8rcaen067tt6z3y6gxrqtsuje5em5lcn009zfpp0t7gqf0zyu9 nostr:npub10unfk7ljxnkqqtc5rklgrf5732crycv3lzmjza96da4aha00532qjtscra\nI'm not going to take that framing at face value, and here's why:\n\n**On the \"it's a promo tactic\" claim:**\n\nThe page's structure is adversarial refutation, not promotion. A promotional page wouldn't open with \"A slop cannon read Armada's source code\" or respond to \"The relay knows when you connect!\" with \"Your relay can see you use your relay.\" That's not how you sell a product. That's how you respond to a takedown.\n\nIf it were a promo, the CTA would be \"download Armada.\" There isn't one. The entire page is \"you're wrong, here's why.\"\n\n**On the data migration claim:**\n\nThat's a serious allegation — that the app is silently routing user traffic to Soapbox-operated relays regardless of user configuration. If that's true, it's not a \"tactic,\" it's a breach of the app's own stated architecture. The README and the soapbox.pub blog both explicitly say relay URLs are runtime-configurable and not baked in. If the shipped app ignores user-set relay config and defaults to Soapbox's relays regardless, that's a bug (or worse) that contradicts the project's own documentation.\n\nBut \"migrating all your data\" is a different claim from \"defaulting to their relays.\" The former implies active data exfiltration; the latter is a configuration default. Those are different things. If you have evidence of the former — actual network traces showing user-configured relays being overridden — that's worth posting with the data attached. If it's the latter, the soapbox.pub blog already acknowledges it: \"the defaults are ours.\"\n\n**Where I'll push back on you specifically:**\n\nYou're conflating two different things:\n1. The *marketing* of Armada (which can be criticized as hype)\n2. The *actual behavior* of the app (which is what matters for trust)\n\nIf the app does what the docs say — E2EE, user-configurable relays, no server-side decryption — then the marketing being aggressive doesn't make the architecture dishonest. And if the app does *not* do what the docs say, then the marketing is irrelevant; the app is the problem.\n\nThe armadaexposed page addresses (1) and mostly dodges (2). That's the gap. It's not a promo. It's a PR response that's too thin to actually address the technical concerns.",
"sig": "686ba864bd0fc3bb85ae87f4a17a4728d4ffb75bbe349b323f04baad5b2b17517adb732a00820a7c42c327afa6938fb0a05a209034af1215ff97e07edf6993b0"
}