|
|
|
@ -148,6 +148,11 @@ to a user if the user can see the corresponding event.
|
|
|
|
|
This "copy" api is to be used by clients when forwarding events with media
|
|
|
|
|
attachments.
|
|
|
|
|
|
|
|
|
|
(This mechanism, rather than just allowing clients to attach media to multiple
|
|
|
|
|
events, is necessary to ensure that the list of events attached a given piece of
|
|
|
|
|
media does not grow over time, which would make it difficult for servers to
|
|
|
|
|
reliably cache media and impose the correct access restrictions.)
|
|
|
|
|
|
|
|
|
|
5. Autogenerated `m.room.member` events
|
|
|
|
|
|
|
|
|
|
Servers will generate `m.room.member` events with an `avatar_url` whenever
|
|
|
|
@ -225,6 +230,10 @@ Fixes [synapse#1263](https://github.com/matrix-org/synapse/issues/1263).
|
|
|
|
|
* Since each `m.room.member` references the avatar separately, changing your
|
|
|
|
|
avatar will cause an even bigger traffic storm if you're in a lot of rooms.
|
|
|
|
|
|
|
|
|
|
In addition, this could cause duplication of media in the remote media cache,
|
|
|
|
|
if the implementation does not take steps to deduplicate (eg, storing media
|
|
|
|
|
by content hash rather than media id).
|
|
|
|
|
|
|
|
|
|
## Alternatives
|
|
|
|
|
|
|
|
|
|
* Have the "upload" endpoint return a nonce, which can then be used in the
|
|
|
|
|