In Telegram, there is a really popular functionality - Channels, anyone with Telegram account can create a channel and publish messages in it, other participants can subscribe and only listen to these channels, they can’t send messages to it
It would be great to have something similar in Status, one reason why, because most channels in telegram anonymous and they’re collecting donations for their work, in Status it could be done in SNT or ETH directly in the channel
How it could be done technically:
It’s not possible to dedicate a topic to some user or prevent sending of messages to this topic, so it could be done on Status App level, we could have a contract where a user could register channel name and randomly generated topic by blocking some SNT, and then in status app when you open this topic we show channel’s name instead topic and hide input field, but if you are owner or admin of this channel in contract you can publish messages in this channel, also we show messages in this channel only which were sent by owner or admin
And anyone could send donations to wallet address registered in the contract right in the channel or as a SNT reaction to messages in the channel
You probably can get away without having to use a contract for this, you can have use conventions for this, the only issue is discovery (how do you find out which channels a user is associated with? ), but you can handle this is different ways.
A simple example:
Every x hours a user propagates a list of “read-only-channels” on his contact-discovery topic (anyone can read this topic, it’s already used and present).
This list is a bunch of names really.
A user fetching this list, will create a bunch of read-only-public-chats (new type of chat), with topic hash(name-of-the-chat-{pk-of-the-user}-read-only-chat), and encryption key hash(name-of-the-chat-{pk-of-the-user}-read-only-chat). We can pass a signature to the filter so whisper is instructed to ignore any message not coming from that signature, but in any case we can do client-side filtering.
The user will not be shown an input when navigating to these chats. If anyone publish on this topic, all the clients will be ignoring it.
So the only issue I see is discovery of the channels, but you can piggy back on any form of storage to do that (mailservers, swarm once that happens etc), topic clashing does not seem to be an issue as far as I can see.
The contract you describe is basically ens names, so why not use that? You can join read-only channels but only the key registered can publish there. They would basically be public channels which start with an @ and by convention wie ignore messages that are not from the registered key.