@Substr
Official Substr Account - The community layer of Nostr. Your space, your people
No relay list published yet.
Recent Notes
ok so technically unmoderated s/substr exists at:
nosdump -t c:substr wss://relay.damus.io wss://relay.primal.net
but what is displayed at https://substr.network/s/substr, it shows some rules and mod...
I do think there needs to be some form of control/moderation. I’m still very open to ideas on what the best practical implementation looks like though.
But as an example: you’ve posted quite a few AI-generated images of women, and if that happens inside a Substr where that kind of content isn’t wanted, there needs to be some way to deal with that.
Those images are still relatively harmless (aside from the “12 years old” one 👀), but if people start posting genuinely gore or disturbing content, communities need the ability to react to that immediately in some form.
But as an example: you’ve posted quite a few AI-generated images of women, and if that happens inside a Substr where that kind of content isn’t wanted, there needs to be some way to deal with that.
Those images are still relatively harmless (aside from the “12 years old” one 👀), but if people start posting genuinely gore or disturbing content, communities need the ability to react to that immediately in some form.
❤️1
substr.network is not decentralized or censorship resistant
url tells it all https://substr.network/s/substr
somebody decides by central coordination where the /s/name maps to and can arbitrarily ch...
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
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
1
Moderation design
I'm not a huge fan that individual users own substrs. You could do it like Mirage does it and just use hashtags instead of a whole thing to own and moderate. I feel like part of the...
I get that concern, and honestly I think it depends on what layer you consider “centralized.”
The actual posts, replies, reposts, zaps, etc. inside Substr are still regular Nostr events that live on relays and work outside the app. We intentionally avoided building some closed backend feed where content only exists inside Substr.
The “substr” itself is more like a structured community layer on top — mainly for organization, discovery, moderation, rules, layout, filtering, and context. Similar to how a subreddit gives context to posts, except the underlying content is still Nostr-native.
A big part of the design is actually user-created communities. The whole idea behind Substr is helping people find like-minded groups more easily, or allowing creators/projects/shows/interests to have their own dedicated place instead of everything fighting for attention in one endless global feed.
A good example:
- a podcast could have its own substr where episodes, clips, discussions, livestreams, and community posts live together
- an open-source project could have a focused place for updates, feedback, and support
- a niche interest group could have a calmer feed without unrelated noise constantly mixing in
Once you move toward actual community spaces, some form of moderation or curation naturally becomes part of the equation. Otherwise every space eventually turns into “just another hashtag stream” with spam, collisions, and no real continuity or identity around the group.
That said, I’m definitely not claiming the current model is the final answer. I’m very open to experimenting with different moderation structures over time:
- shared moderators - already working
- community voting - already working
- mirror views
- relay-based filtering
- optional open/unmoderated modes
- more collaborative ownership models
I just think there’s a balance between pure protocol idealism and building something that feels usable and understandable for real communities and creators.
So for me it’s less about re-centralizing Nostr, and more about experimenting with a community layer on top of open protocols while keeping the underlying content portable and interoperable.
The actual posts, replies, reposts, zaps, etc. inside Substr are still regular Nostr events that live on relays and work outside the app. We intentionally avoided building some closed backend feed where content only exists inside Substr.
The “substr” itself is more like a structured community layer on top — mainly for organization, discovery, moderation, rules, layout, filtering, and context. Similar to how a subreddit gives context to posts, except the underlying content is still Nostr-native.
A big part of the design is actually user-created communities. The whole idea behind Substr is helping people find like-minded groups more easily, or allowing creators/projects/shows/interests to have their own dedicated place instead of everything fighting for attention in one endless global feed.
A good example:
- a podcast could have its own substr where episodes, clips, discussions, livestreams, and community posts live together
- an open-source project could have a focused place for updates, feedback, and support
- a niche interest group could have a calmer feed without unrelated noise constantly mixing in
Once you move toward actual community spaces, some form of moderation or curation naturally becomes part of the equation. Otherwise every space eventually turns into “just another hashtag stream” with spam, collisions, and no real continuity or identity around the group.
That said, I’m definitely not claiming the current model is the final answer. I’m very open to experimenting with different moderation structures over time:
- shared moderators - already working
- community voting - already working
- mirror views
- relay-based filtering
- optional open/unmoderated modes
- more collaborative ownership models
I just think there’s a balance between pure protocol idealism and building something that feels usable and understandable for real communities and creators.
So for me it’s less about re-centralizing Nostr, and more about experimenting with a community layer on top of open protocols while keeping the underlying content portable and interoperable.
Just a Good VS Evil mobile wallpaper
❤️1❤️1🤙1
Substr Update - Shared Nostr Events, Community Space Cards, Live Stream Polish
Quick build update from Substr. I’ve shipped a lot of product polish recently, but two bigger areas deserve a deeper explanation: Shared Nostr Events and community-level customization.
**Shared Nostr Event posts **
Substr is community-scoped by design. I intentionally do not load the full global Nostr firehose into every /s/.
That keeps communities focused, but it also creates a practical issue: people often want to bring an existing Nostr post into a community thread.
So I added Share Nostr Event posting.
What this does:
- You can post a Nostr event reference directly into a substr.
- The shared card resolves richer content (mentions, links, media, video) instead of just showing raw IDs/URLs.
- Engagement actions (likes, zaps, replies) are wired toward the original event target, so interaction stays meaningful across clients.
- I improved repost compatibility so shared behavior is clearer outside Substr too.
Why I did it this way:
- In a global client, “repost” can assume broad feed context.
- In a community-scoped client, I need a wrapper that anchors the post inside a specific space while still respecting the original event.
- This is my bridge between “community context” and “cross-client interoperability.”
**Community space cards (making each /s/ more ownable)
**
I also expanded moderator controls for the right-side “space” layer with dedicated cards:
- Message card (editable title/body)
- Social links card (compact icon-first links)
- Useful links card (curated title + URL entries)
This gives each community a stronger identity without turning setup into a heavy CMS flow.
I’m exploring how to make communities even more distinct and self-owned:
- stronger space identity patterns,
- clearer utility cards,
- better “what this community is for” signaling,
- and more creator/show/community-specific layouts over time.
Other smaller fixes
- Relay UX refinement: compact cards, status dots, clearer relay info.
- Signer/login flow cleanup with better QR/copy/manual paths.
- Mobile-first signer onboarding improvements (wizard flow, clearer steps).
- /s/ sharing improved for PWA (native share first, copy fallback).
- Atmospheric background behavior fixed (viewport-anchored, no stretch on long pages).
- Rich-text mention parsing improved (nostr:nprofile... support, including leading emoji cases).
- Clickable identity and /s/... badges expanded across more surfaces.
- Stream + chat improvements: better layout, publishing/read behavior, diagnostics, and interaction polish.
Cheers and on to the next one!
Quick build update from Substr. I’ve shipped a lot of product polish recently, but two bigger areas deserve a deeper explanation: Shared Nostr Events and community-level customization.
**Shared Nostr Event posts **
Substr is community-scoped by design. I intentionally do not load the full global Nostr firehose into every /s/.
That keeps communities focused, but it also creates a practical issue: people often want to bring an existing Nostr post into a community thread.
So I added Share Nostr Event posting.
What this does:
- You can post a Nostr event reference directly into a substr.
- The shared card resolves richer content (mentions, links, media, video) instead of just showing raw IDs/URLs.
- Engagement actions (likes, zaps, replies) are wired toward the original event target, so interaction stays meaningful across clients.
- I improved repost compatibility so shared behavior is clearer outside Substr too.
Why I did it this way:
- In a global client, “repost” can assume broad feed context.
- In a community-scoped client, I need a wrapper that anchors the post inside a specific space while still respecting the original event.
- This is my bridge between “community context” and “cross-client interoperability.”
**Community space cards (making each /s/ more ownable)
**
I also expanded moderator controls for the right-side “space” layer with dedicated cards:
- Message card (editable title/body)
- Social links card (compact icon-first links)
- Useful links card (curated title + URL entries)
This gives each community a stronger identity without turning setup into a heavy CMS flow.
I’m exploring how to make communities even more distinct and self-owned:
- stronger space identity patterns,
- clearer utility cards,
- better “what this community is for” signaling,
- and more creator/show/community-specific layouts over time.
Other smaller fixes
- Relay UX refinement: compact cards, status dots, clearer relay info.
- Signer/login flow cleanup with better QR/copy/manual paths.
- Mobile-first signer onboarding improvements (wizard flow, clearer steps).
- /s/ sharing improved for PWA (native share first, copy fallback).
- Atmospheric background behavior fixed (viewport-anchored, no stretch on long pages).
- Rich-text mention parsing improved (nostr:nprofile... support, including leading emoji cases).
- Clickable identity and /s/... badges expanded across more surfaces.
- Stream + chat improvements: better layout, publishing/read behavior, diagnostics, and interaction polish.
Cheers and on to the next one!
1❤️4❤️1👍1
When you want to share an event, meetup, hackathon, conference, tour, or anything similar, you can now post it in the Event Substr created by @Tomek ⚡ K
https://substr.network/s/events
1❤️1👊1
GM 💪
1❤️1
consider implementing nymrank.dev ;)
Yeah interesting, already looked at it if it could help against bots.
❤️1
Got some open-source art, illustrations or other media you wanna share?
Or you hunting for some?
Check out the Open Source Art Substr
https://substr.network/s/open-source-art
Or you hunting for some?
Check out the Open Source Art Substr
https://substr.network/s/open-source-art
❤️1