matrix-org / matrix-spec-proposals

Proposals for changes to the matrix specification
Apache License 2.0
994 stars 376 forks source link

Proposal for improved bot support #3800

Open turt2live opened 6 years ago

turt2live commented 6 years ago

Documentation: https://docs.google.com/document/d/13ec6iqTQc7gMYGtiyP6qkzsgi3APVwuoXqJFHrfLEP4/edit?usp=sharing Date: 14/03/2018

benparsons commented 6 years ago

@turt2live I have standardised your top comment, details will come from the soon-to-arrive spec proposals tracker.

turt2live commented 6 years ago

kinda note to self: may be worth considering https://github.com/matrix-org/matrix-doc/issues/1242 in this proposal

turt2live commented 6 years ago

@benparsons when you get a chance, this can be moved to ready-for-review. I'm not sure which core team member to make the victim for review though.

benparsons commented 6 years ago

@turt2live is done. Website cron tomorrow morning.

I will be away next week, suspect @ara4n will be most likely pingable entity for this kind of request (sorry chief!), also @uhoreg if he has permission?

turt2live commented 6 years ago

It's open to the community to review, although iirc the proposal process requires someone from the core team to look it over as well. If both reviewed it, that'd be awesome :)

KitsuneRal commented 6 years ago

An interesting thing, I overlooked that. Would be great to see it in the spec by the end of the year :)

zeratax commented 4 years ago

don't have much to add, just want to say that I really love this and hope it's not being forgotten.

Also kinda wondered if clients then should show users what the bot will see (what commands this bot supports) before actually inviting a bot to a room so that a user can make an informed decision. though I'm unsure what should happen when a bot introduces m.bot key when it's already in the room or changes what commands it supports. would be nice if a bot couldn't just introduce passive commands without users (or at least admins/moderators) in the room being aware of that.

but that's probably out of scope for this proposal.

auscompgeek commented 4 years ago

Also kinda wondered if clients then should show users what the bot will see (what commands this bot supports) before actually inviting a bot to a room so that a user can make an informed decision.

This would likely require extensible profiles (#489).

smithfred commented 2 years ago

Just to mention that because all of the content of this proposal is in a Google Doc (somewhat ironically, for a privacy-focused/open protocols project!), it's pretty difficult to find this when searching for issues relating to E2EE and bots. Maybe someone with privileges could tag this issue with e2e and whichever other tags are relevant?

Also, tangentially, anyone know if https://element.io/integration-manager-privacy-notice is incomplete in regard to when data might be exposed to 3rd parties?

Bots
All unencrypted events in rooms in which a Element-managed bot is participating are theoretically visible to New Vector.

Wouldn't that also extend to encrypted events if the Element-managed bot supports participation in E2EE rooms? Or do none of the bots they make available support E2EE currently?

Adding some keywords here for searchability: encryption, integration, widget.

turt2live commented 2 years ago

This MSC was written about 4 processes ago - for it to get maintenance, it'd be converted to markdown like all the rest. As people have mentioned, this MSC is largely blocked behind other MSCs so there's not much interest in keeping it up to date at the moment.

Also, tangentially, anyone know if https://element.io/integration-manager-privacy-notice is incomplete in regard to when data might be exposed to 3rd parties?

This seems offtopic for this discussion. I'd recommend asking the integration manager team at Element for more information (possibly via a support email of some kind).