Address comments about via and the URIs that should be used.

proposals/4132-deprecate-event-on-room-alias-uris.md

@@ -23,9 +23,14 @@ The proposal would [deprecate](https://spec.matrix.org/v1.10/#deprecation-policy
 - Link to `$event` in `#somewhere:example.org`: `https://matrix.to/#/%23somewhere:example.org/%24event%3Aexample.org`
 
 Specifically this means it would be marked in the spec as not to be used in future and clients should:
-1. Stop making new event URIs with room aliases.
+1. Stop making new event URIs with room aliases, generating the examples above as the following respectively:
+    - `matrix:roomid/opaqueid:example.org/e/event?via=example.com`
+    - `https://matrix.to/#/!opaqueid%3Aexample.org/%24event%3Aexample.org?via=example.com`
 2. Continue to accept them as it will take time for other clients to update and legacy events will continue to exist.
 
+It is worth nothing that this change would require clients to always add the `via=` fields when building event URIs as
+these are expected for URIs that reference a room ID.
+
 
 ## Potential issues
 
@@ -33,6 +38,10 @@ Whilst most clients do take the sensible route and generate event URIs against a
 it is part of the spec these kinds of links likely exist somewhere in room history and on the World Wide Web. This would
 mean that after deprecation clients may still want to handle these URIs when received.
 
+Additionally, whilst not a new problem some clients don't always update the `via` fields, which poses a problem for
+rooms that have lots of single user homeservers: A single user leaving can result in the `via` to become non functional
+(which is essentially the equivalent of the alias being removed) and over time this can result in unreachable room IDs.
+
 
 ## Alternatives