| 17 Apr 2021 |
 Jonathan |
- define a series of imperative-declarative operations, e.g. "insert this value into array
.users.ignored" or "set this value of ."im.vector.breadcrumbs" to [...] if value .lastedited is "<date>"", basically doing a lot to ensure that account_data edits are as predictable yet race-free as possible, atomic edits
| 08:41:07 |
| Jonathan |
- define an endpoint that lists account_data keys with 'sideffects', like rn it could be
m.ignored_users, but in the future it might be a lot more, it might even be dependent on implementation, and so - for security, but also for discovery - it'd be useful if those side_effects are programmatically determinable with that endpoint
| 08:42:24 |
| Jonathan | just an array of account_data keys that arent "just storage" | 08:42:33 |
| Jonathan | In reply to @jboi:jboi.nl
- define an endpoint that lists account_data keys with 'sideffects', like rn it could be
m.ignored_users, but in the future it might be a lot more, it might even be dependent on implementation, and so - for security, but also for discovery - it'd be useful if those side_effects are programmatically determinable with that endpoint
(for security, cuz bots might store "cookies" or account data with interactions, and it's possible those could clash with account data that has sideeffects and the like) | 08:51:04 |
 tulir | why would you store anything in an account data event that you don't know about? | 08:54:22 |
| Jonathan | wym "dont know about"? | 08:55:54 |
| Jonathan | why set cookies? :P | 08:55:57 |
| tulir | how would account data "clash" with anything? | 08:56:21 |
| Jonathan | cuz some account_data keys would have "sideeffects" | 08:56:42 |
| Jonathan | such as ignored users, or archived rooms | 08:56:49 |
| tulir | if you want to ignore users, then you put something in m.ignored_users
if not, then you don't put anything in m.ignored_users
I don't see where any kind of clash comes in
| 08:56:59 |
| Jonathan | the clash might be if its like | 08:57:45 |
| Jonathan | famedly brings out a modded homeserver, and then something/someone would wanna store to de.famedly.friends or whatever | 08:58:12 |
| Jonathan | if the client doesnt know it deliberately causes "side effects", its effectively a CSRF, but on matrix | 08:58:37 |
| tulir | oh you mean the client allowing a 3rd party to set account data | 08:59:45 |
| Jonathan | yeh | 09:00:16 |
 Nico | Imo if we get scoped access tokens, they should only allow access to namespaced account data keys or whitelisted ones | 09:00:24 |
| tulir | In reply to @jboi:jboi.nl
yeh that might depend on what the 3rd party is | 09:01:32 |
| tulir | like if it's a widget that wants to store configuration, probably easier to just limit it to using the source domain's namespace | 09:02:12 |
| Jonathan | shrug | 09:03:57 |
| Jonathan | still | 09:03:58 |
| Jonathan | its as much a security feature as it is a discovery feature | 09:04:10 |
| Jonathan | im just putting it in here for the idea | 09:04:15 |
| tulir | the discoverability side is kind of useless: "de.famedly.friends has side-effects" doesn't tell you what it does | 09:07:43 |
 Erkin Alp | you can't force everyone to open source their side effect code | 09:08:32 |
| Nico | Also all account data has side effects, otherwise you wouldn't store it, would you? | 09:09:16 |
| Nico | It just has less or more visible effects | 09:09:33 |
| tulir | that too, most of the effects are just client-side rather than server-side | 09:13:03 |
| Nico | Yeah, but a random client modifying those will still mess up stuff for the user | 09:13:40 |
|  ⏣sapient_cogbag⏣[ⒶH⁺⚧★][they/them|ze/zem|xe/xem] changed their display name from ★⚧[Ｈ⁺]Ⓐ⏣sapient_cogbag⏣Ⓐ[H⁺]⚧★ [they/them | ze/zem | xe/xem] to ⏣sapient_cogbag⏣[ⒶH⁺⚧★][they/them|ze/zem|xe/xem]. | 09:16:18 |
