declare not forward-able apps in manifest

[adbenitez]

bots can benefit greatly of using webxdc apps as UI interfaces to its functionality rather than command-based usage,

one usability issue tho, is that for users it is not 100% clear that these apps can only work with the bot, and they shouldn't be forwarded or keep working if the bot gets removed for the group etc.

so it is needed a way to declare in the app manifest: "this app is tied to the sender/bot" so if the bot is not in the group or 1:1 it is clear the app can not work as expected, as an initial step, this flag could be used just to prevent/disable forwarding of the app to other chats

[Simon-Laux]

I don't like the idea of restricting the user, I would say it's up to the app dev to show a message in the app. maybe a warning dialog at most, restricting even download feels like DRM to me, also it is a bit against the idea of openness: xdcs are just zip files that you can inspect if you like.

In my opinion you can disable forwarding, but downloading should stay an option.

[hpk42]

It's not about preventing "download/save as" but to think how to prevent usage problems with XDCs that require a bot and can not function without one. We don't have any such xdc+bot apps in any wider use so let's not try to nail this down further right now and just leave the issue as a reminder.

[adbenitez]

some apps like the appstore, simply are empty apps that can't work without the bot, so there is no point in allowing forwarding the app, and it is a common case an user will try to do "lets forward this app store to my friend so she can download some apps"

and it is about preventing that with a manifest field, if the app developer use it is for a reason

now that doesn't prevent user from using the share button on android, or the "export attachment" and then sending the app if you really want, but then in staged area first, where you can open it and realize it is empty and more clear from other app usage that when the app is staged it is a new empty instance, which is not that obvious when you use the forward button, you expect to forward the actual instance you are selecting with its current state

in fact I think in general we should change the action for all xdc files and instead of forwarding directly xdc files, put them in staging mode

[r10s]

i agree there should be at least a warning - if that can be in-app somehow, indeed, that would be best as no ui changes are required.

also so the app could say exactly what is needed to fix the issue

not sure if that can be detected with the current apis, however

in fact I think in general we should change the action for all xdc files and instead of forwarding directly xdc files, put them in staging mode

it is getting offtopic, however, we should also consider to forward app+state in this case. i am not sure what were the reasons to not do that, but from user view that seems quite natural

[hpk42]

if we want to do something about "bot-requiring" webxdc apps, it's maybe better to think directly about this. Also, we have exactly one real-world example, namely the xstore bot, and it has usability issues wrt self-updating, and it's not yet usable from Cheogram, both are more important (untackled) issues.

Also, maybe webxdc frontends to bots become a new "chat type" rather, so that receiving delta chat's show the app in the chatlist and there is no message-view and no ability to forward at all?

In any case, I don't think it makes sense to decide this right now, and adding something to the spec/manifest is doc/spec work and implementation and UI is some work, probably better spent in other areas of webxdc. So i am closing this for now.