feat: introduce webxdc appSenderAddr and canOnlySendUpdatesToAppSender

[hpk42]

This allows apps to behave differently, depending on the sending context.

A corresponding PR to make it available in Delta Chat is in

chatmail/core#8133

The spec change should not be merged before it is successfully released, and can be used a bit in practise.

[r10s]

core implementation at chatmail/core#8133

[Amzd]

discussed with @hpk42 more and we think it makes sense to change to:

appSenderAddr = string
canSendUpdatesToAllPeers = true | false

this makes sure to not introduce a "broadcast" term to the spec of webxdc because in the context of w2g.tv this same concept of "only the app sender can send updates" might be called "host" instead.

Note that we need to amend the spec for sendUpdate to not say "Send an update to all peers." but instead send updates to peers based on webxdc.canSendUpdatesToAllPeers.

[WofWca]

So what would canSendUpdatesToAllPeers === false mean? That you can only send updates to some peers? That you can only send them to yourself? That you can't send them at all?

[Amzd]

It would mean that you can only send to sender, this can be clarified in the documentation.

If you mean you want to keep open the option to send updates only to a subset of peers I'd suggest

canSendUpdatesTo = "all" | "sender" (| addr[])

but that complicates the proposed api quite a bit.

[r10s]

canSendUpdatesTo = "all" | "sender" (| addr[]) was discussed to be too complex and not needed in the foreseeable future. if really needed, we can add that, but it will likely not happen.

i adapted chatmail/core#8133 which is ready for review now

[r10s]

it is false also for one-to-one chats, maybe worth to say that explicit.

if true, question pops up if SELF is seeing the update - there are few situations where SELF do not get updates already today, eg. if one cannot sent in a chat, on chat requests. as the state comes from the channel owner only, it might be better here as well. but not sure, just mentioning

[Amzd]

I assumed that

All receiving peers, including the sending one, will receive the update

in sendUpdate.md implied that you get your own updates even if you are not sender, maybe I was wrong in my review on the core PR

[r10s]

with the latest changes, we destroyed the initial idea of knowing if one is on a broadcast or not.

canOnlySendUpdatesToAppSender is obviously false for the channel owner. and can be calculated by sender equals self.

tbh, with all the added complexity, i am sceptical if the recent changes were improvements. isBroadcast/isAppSender was easy, clear and simple. the added functionality is questionable and it is not clear if it is will be used, and in which future. the usecase of state handling ("Centralized coordination") would be possible by isAppSender as well.

also, the calculation of sender is not simple, and has cornercases, where it is undefined. it will also be harder for xmpp, and other hosts. all solvable, sure, but i am afraid we're adding complexity here, that has limited use at the end, and needs to be maintained for a long time.

alone by the not obvious pitfalls, it is questionable. maybe better do sender context in another discussion, there is the idea of putting that outside payload etc.

we're often saying, that we want to be on point, but that seems not the case here.

i am suggesting to revert to the initial idea

[hpk42]

closing this in favor in of #137