The actual posts and interactions inside Substr are still Nostr events on relays, so the content itself is portable and interoperable. That also means your posts can still reach far beyond just Substr itself, instead of being trapped inside a closed platform or isolated community silo. That wider reach and interoperability is a pretty important part of why I chose this hybrid approach in the first place.
But yes, the mapping layer of /s/name currently lives inside Substr’s own infrastructure.
As for why I’m not fully using the current community NIPs (like NIP-72/29) yet:
I experimented with them quite a bit, but right now they still have a lot of rough edges for the type of UX and moderation flow I want to build:
weak discovery
inconsistent relay support
fragmented moderation behavior
poor UX for mainstream users
difficulty building structured feeds/community identity
limited flexibility around permissions, layouts, ranking, and management
A big goal of Substr is making communities feel understandable and approachable for normal users, not just protocol-native users.
So the current approach is more of a pragmatic hybrid:
communities/substrs live in a DB layer for now
content inside them stays Nostr-native
users still own their identities/accounts/content
posts still exist outside Substr
interoperability is preserved where possible.
Long term I’d absolutely like to move toward more decentralized community models once the ecosystem and standards mature more
Substr
npub122…nfgdf
2026-05-18 17:06:49 UTC
in reply to nevent1q…sp7n
Author Public Key
npub122wdrxx9gaf6reg52nzcd4m5u66qx85jm3c9gwgrsukkcelm0u2q0nfgdfPublished at
2026-05-18 17:06:49 UTCEvent JSON
{
"id": "67267cc3e94e3aad3c46333f3383416c8b1d68de9f9f50ed8db981fda5fa8074",
"pubkey": "529cd198c54753a1e51454c586d774e6b4031e92dc70543903872d6c67fb7f14",
"created_at": 1779124009,
"kind": 1,
"tags": [
[
"e",
"10498b551546c23706111d5d191850fe6d7e9cc9d784f928d876832df41c7caf",
"",
"root"
],
[
"p",
"af7dba05e544d4269f6e4ec6762f19326205e02a33b025e3aff7727c27672f2c"
],
[
"c",
"substr"
],
[
"client",
"Substr"
]
],
"content": "The actual posts and interactions inside Substr are still Nostr events on relays, so the content itself is portable and interoperable. That also means your posts can still reach far beyond just Substr itself, instead of being trapped inside a closed platform or isolated community silo. That wider reach and interoperability is a pretty important part of why I chose this hybrid approach in the first place.\n\nBut yes, the mapping layer of /s/name currently lives inside Substr’s own infrastructure.\n\nAs for why I’m not fully using the current community NIPs (like NIP-72/29) yet:\nI experimented with them quite a bit, but right now they still have a lot of rough edges for the type of UX and moderation flow I want to build:\nweak discovery\ninconsistent relay support\nfragmented moderation behavior\npoor UX for mainstream users\ndifficulty building structured feeds/community identity\nlimited flexibility around permissions, layouts, ranking, and management\nA big goal of Substr is making communities feel understandable and approachable for normal users, not just protocol-native users.\nSo the current approach is more of a pragmatic hybrid:\ncommunities/substrs live in a DB layer for now\ncontent inside them stays Nostr-native\nusers still own their identities/accounts/content\nposts still exist outside Substr\ninteroperability is preserved where possible.\n\nLong term I’d absolutely like to move toward more decentralized community models once the ecosystem and standards mature more",
"sig": "ad95b6efa10a7aa9fa908f0e60ea042701bf61157e547f49c276fbad327a145a43ccf15410fd657b40ceb3e0d388b3474813512704c05b64ea6e1fea5cb8892d"
}