Ability for server admins to write-to-all (aka WALL, broadcast) to users on their server

[ara4n]

We have some bugs which touch on this: #67 and possibly matrix-org/synapse#1286.

Filing as a spec bug as we should probably recommend the best way to do this. Options are:

• Force-join users to a read-only broadcast room on the server (on demand?) - possibly using Groups? or just as special cased behaviour on the server or an AS?
• Maintain a tonne of 1:1s between server admins & users, with some kind of way to help the server admins manage the resulting mess. Gives option for 2-way discussion though.
• Use to_device messages?
• ...?

[Ezwen]

Option 2 seems better than Option 1, as it would avoid disclosing the list of all users of the server, to each user of the server.

Anyway, would love to see this feature to be able to broadcast planned downtimes to users :)

[KitsuneRal]

Regarding specifically planned downtimes - I'd rather recommend using a separate room for that (with force-joining but otherwise a usual room). Then people who don't care so much would be able to unsubscribe from the room.
As for completely out-of-band WALL-style cases - I'd say that to_device is a waste for that. Probably a special kind of a room would be good, one that doesn't share its m.room.member and probably some other types of events (addressing @gwend4l's concern above and also maaassively reducing /sync payloads for such room). 2-way discussion is a completely separate thing from WALL and should be established separately (a @support: or @admin: user account immediately comes to mind). Very few people actually have something to say to admins, even fewer have something useful.

[ghost]

I'd say go with a special room. The room can be "fake" i.e. not actually backed by a DAG but supporting all the necessary client-side endpoints. This also opens the way to all kinds of special semantics, including hiding the user list and directing any talkback to the server admin (only), if so desired.

[vsund]

Regarding specifically planned downtimes - I'd rather recommend using a separate room for that (with force-joining but otherwise a usual room). Then people who don't care so much would be able to unsubscribe from the room.

@KitsuneRal Would this result in a public list with all members? At least for my usecase I'd like to avoid this :)

[KitsuneRal]

@vsund - you're right, and this probably makes a case for a special kind of room, one tailored for broadcasting from a small group of authors ("publishers" or "administrators") to many readers ("subscribers" or "audience"). If I don't mistake, this format is quite popular in Telegram, by the way. Such room would notably hide users from each other, while still providing proof of identity of those who publish in it.

As an afterthought - "official accounts" for brands could also be established using this kind of rooms, with potentially millions of subscribers reading the messages without having to cope with room states of tremendous size at least on the client side.

[Half-Shot]

Honestly I'd prefer to keep it short and simple and have a broadcast room, and then just have a discussion room for those that want to discuss anything. The vast majority will ignore your message anyway, and even less will want to reply. Those that do can use a dedicated announcement-discussion channel.

[Half-Shot]

This is vastly easier now we have System Alert rooms?

[turt2live]

The proposal is here, and not yet merged or approved: matrix-org/matrix-spec-proposals#1452

[uhoreg]

Is this fixed by system alerts now?

[turt2live]

System alerts are not in the spec to the capability this requires.

[wioxjk]

What is the status of this?

[KeenMaron]

Hi!
Any updates? :)

[Saiv46]

I think there's more clean solution to that... How about RSS?

Server can expose GET /_matrix/client/v3/feed API, which responses with:

{
  "chat": "<discussion-room-id>",
  "url": "https://<server-name>/path/to/feed.xml",
  "creator": "<admin-id>",
  "name": "<channel-name>"
}

(All parameters are optional)

[Saiv46]

Unfortunately, full-pledge channels are not implemented yet in Matrix, so there's easier-to-implement solution which:

+ Respects privacy (RSS can't track whatever post you're reading)
+ Easily cachable (both the API response and RSS feed)
- Don't have subscriber/view count
- There's no built-in tools to maintain RSS feed

[wioxjk]

I may be stupid, but does'nt that require users to follow the RSS-feed manually instead of admins being able to "push out" the notification?
@Saiv46

[Saiv46]

Sorry for absence, here I answer the question

I may be stupid, but does'nt that require users to follow the RSS-feed manually instead of admins being able to "push out" the notification?

@wioxjk I think Matrix protocol should handle messages only, while channels (basically RSS-feeds) should be implemented by Matrix clients as something distinguishable (other we get a mess just like in Telegram/Whatsapp/etc).