I came to Nostr hoping to invite some interest groups here. Some of these groups are engaged in lawful activity that is illegal in their region. Being able to chat together, without any other eyes on the conversation, is required.
A client (and relay generator) aimed at topic-specific relays would be great. With the ideas described above, I see a variation that might work.
- There would be no main feed
- Upon opening the app, a list of subscribed/joined groups would be presented (onboarding and initial setup would be different)
- Selecting a group would open the feed for that group. There may be other areas present here, like a media gallery, and list of attendees.
- Creating a group would create a relay for that group. Any relay management aspects that are not specific to group communication should be as minimal as possible. Most group organizers have no interest in being a network/server admin.
- The app must be able to handle as many relays as the number of contacts and interests a person would have (plus a percentage as a fudge factor). I'm thinking 10,000 would be a safe number, but maybe that's low.
- The app must be able to handle running as many relays as a person, or organization, could manage. My guess would be "at least 1,000", but that number may also be low.
- All communications in a group would be encrypted, preventing outsiders from seeing the content.
- Group members would not be known to an outsider of the group.
- DM's must be 100% reliable. If one doesn't reach its destination, the sender must be notified. Messages shouldn't randomly disappear after being read either. This is how group organizers will be notified that someone wishes to join, and how an approval method will sent back to them. It's also how group members will communicate when a message may not be needed, or appropriate, for the group.
There are plenty of other requirements, like how banning someone would work, but the points above are a base to work from.
Troy
npub104…285rf
2026-02-23 16:22:57 CET
in reply to nevent1q…94jv
Author Public Key
npub104zp04wlgddf0w84tj8jul3w75e7ydcuuhsull2etste5040xm2qg285rfPublished at
2026-02-23 16:22:57 CETEvent JSON
{
"id": "c5f016288538e1d17ada182de7ddf012e8d72e16dcf1ba26c2109f2da5b77f7d",
"pubkey": "7d4417d5df435a97b8f55c8f2e7e2ef533e2371ce5e1cffd595c179a3eaf36d4",
"created_at": 1771860177,
"kind": 1,
"tags": [
[
"e",
"7444a4df2d03bbe7ef777e1bf8392e7f36b63b163e3ad6deb36eabd3b6517ed2",
"",
"root"
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
]
],
"content": "I came to Nostr hoping to invite some interest groups here. Some of these groups are engaged in lawful activity that is illegal in their region. Being able to chat together, without any other eyes on the conversation, is required.\n\nA client (and relay generator) aimed at topic-specific relays would be great. With the ideas described above, I see a variation that might work.\n\n- There would be no main feed\n\n- Upon opening the app, a list of subscribed/joined groups would be presented (onboarding and initial setup would be different)\n\n- Selecting a group would open the feed for that group. There may be other areas present here, like a media gallery, and list of attendees.\n\n- Creating a group would create a relay for that group. Any relay management aspects that are not specific to group communication should be as minimal as possible. Most group organizers have no interest in being a network/server admin.\n\n- The app must be able to handle as many relays as the number of contacts and interests a person would have (plus a percentage as a fudge factor). I'm thinking 10,000 would be a safe number, but maybe that's low.\n\n- The app must be able to handle running as many relays as a person, or organization, could manage. My guess would be \"at least 1,000\", but that number may also be low.\n\n- All communications in a group would be encrypted, preventing outsiders from seeing the content.\n\n- Group members would not be known to an outsider of the group.\n\n- DM's must be 100% reliable. If one doesn't reach its destination, the sender must be notified. Messages shouldn't randomly disappear after being read either. This is how group organizers will be notified that someone wishes to join, and how an approval method will sent back to them. It's also how group members will communicate when a message may not be needed, or appropriate, for the group.\n\nThere are plenty of other requirements, like how banning someone would work, but the points above are a base to work from.",
"sig": "7f938d1387e16f9a49e50f3a5ed4355da52b808201739685956e6ff6db23b958626cdd39397c753be234c1f6eb1bdec49c0e46cde811c6e2310030271d492a52"
}