Reconsider deprecating NIP-28: NIP-29 puts too much burden on relays

[ShinoharaTa]

Hi, I want to discuss the deprecation of NIP-28. I understand NIP-29 (Relay-based Groups) is great for moderation, but I believe NIP-28 should not be deprecated. NIP-28 and NIP-29 have different use cases.

Here is why NIP-28 is still necessary:

1. Too much burden on relay operators
Nostr relays should be simple. NIP-29 forces relays to manage user roles, permissions, and bans. This increases server costs and moderation responsibility for relay operators.

2. Single Point of Failure (Centralization)
NIP-28 channels can be mirrored across many relays. If one relay goes down, the channel survives.
NIP-29 depends on a specific relay. If that relay goes offline or censors the group, the whole community dies. This is similar to Discord, not a decentralized Nostr.

3. Hard to discover (Not democratic)
In NIP-28, anyone can easily find and join a public channel.
In NIP-29, users cannot join unless they know the specific relay URL. This makes the chat closed and less democratic.

Conclusion:
NIP-29 is good for managed communities, but it is not a replacement for NIP-28. We still need NIP-28 for truly open, permissionless public chats. Please consider removing the deprecated tag from NIP-28.

[fiatjaf]

NIP-28 can still be used.

Are you using it? What clients support it?

[ShinoharaTa]

@fiatjaf
Thankyou.

Yes, I am using it. I provide a Public Chat web service based on NIP-28.

https://nchan.vip

It is inspired by "2channel" (a very famous anonymous message board in Japan). It works as an anonymous chat where users use disposable private keys that change daily.
To manage the channels, I also run a custom API that provides a list of threads so users can fetch and sort the latest channels easily.

(Insert API response structure here)

*Note: This service is highly optimized for the Japanese community, so I am not sure how well it displays or works in external environments.

Regarding other clients and use cases, there are several NIP-28 public chats in the Japanese community. We also have a unique culture where users create their own NIP-28 threads just to organize their thoughts quietly.

Here is another Japanese client that supports NIP-28:
https://nos-haiku.pages.dev/

[fiatjaf]

https://nchan.vip

This seems to work with a few hardcoded Japanese relays. One of your points was that it was hard to discover NIP-29 groups, but this is the same: you still have to know what are the relays being used. NIP-29 makes this explicit.

Maybe you don't need NIP-29, but I still think you need something better than NIP-28 for your use case. At least something that acknowledges its tradeoffs.

What happens if I create a spam bot and start flooding the channels on your app?