Michael (t3chguy) there are scopes APIs for getting things like members etc, each of those will ask the user for permission for that scope of access
Michael (t3chguy) but giving an access token gives up your entire account pretty much.
Asbjørn What is the "community consensus" on supporting features out of spec?
I'm noticing that a lot of super common stuff (edits and reactions) isn't actually in the spec.
It sort of seems like one has to support MSCs that aren't in the specification in order to be compatible with the ecosystem.
For instance, Element users will use edits liberally, which will show up weird in a strictly spec-compliant client.
Do people normally just support whichever features Element/Synapse currently does?
Šimon Brandner As far as I know this is a bit more complex. I am not sure but #matrix-spec:matrix.org might be better for this 🤷♂️
tulir people support whichever features they want, not necessarily what element/synapse does
tulir custom emojis and mark as unread come to mind as features element doesn't do
Asbjørn > <@tulir:maunium.net> custom emojis and mark as unread come to mind as features element doesn't do
afaik those are out of spec. element also doesn't implement stuff that is in spec, like m.location events
Asbjørn > <@tulir:maunium.net> people support whichever features they want, not necessarily what element/synapse does
but it seems like clients are forced to implement out-of-spec features in order to be compatible with element?
Asbjørn > <@tulir:maunium.net> people support whichever features they want, not necessarily what element/synapse does- but it seems like clients are forced to implement out-of-spec features in order to be fully compatible with element?
tulir those are spec proposals just like edits and other such features
tilde > <@asbjorn:olli.ng> What is the "community consensus" on supporting features out of spec?
I'm noticing that a lot of super common stuff (edits and reactions) isn't actually in the spec.
It sort of seems like one has to support MSCs that aren't in the specification in order to be compatible with the ecosystem.
For instance, Element users will use edits liberally, which will show up weird in a strictly spec-compliant client.Do people normally just support whichever features Element/Synapse currently does?
MSCs are for when they are on the track towards the spec, and those clients and servers who want to support features before they're finished and merged into the spec can use those MSCs to implement them
tulir > <@asbjorn:olli.ng> but it seems like clients are forced to implement out-of-spec features in order to be fully compatible with element?
edits and reactions were a bit of a mistake in terms of the spec process, but element will probably always implement spec proposals before they're in the spec
tulir although they'll probably try to keep the features in labs until the MSCs are approved (like spaces are being developed now)
tilde Well they'll implement the spec proposals that they introduced
tulir > <@asbjorn:olli.ng> but it seems like clients are forced to implement out-of-spec features in order to be fully compatible with element?- edits and reactions were a bit of a mistake in terms of the spec process, but element will probably always implement some spec proposals before they're in the spec
tilde for example they haven't implemented e.g. custom emoticons, those are an MSC that someone else proposed (and other people have implemented in their clients to demonstrate the feasibility)
Jonathan (@jboi:jboi.nl) > <@asbjorn:olli.ng> What is the "community consensus" on supporting features out of spec?
I'm noticing that a lot of super common stuff (edits and reactions) isn't actually in the spec.
It sort of seems like one has to support MSCs that aren't in the specification in order to be compatible with the ecosystem.
For instance, Element users will use edits liberally, which will show up weird in a strictly spec-compliant client.Do people normally just support whichever features Element/Synapse currently does?
the spec-impl situation is a mess
Jonathan (@jboi:jboi.nl) * the spec-impl situation is a mess rn
Jonathan (@jboi:jboi.nl) and its slowly converging to a more coherent whole
Jonathan (@jboi:jboi.nl) there was a lot of unstable features in production, still is
Jonathan (@jboi:jboi.nl) heck, the DM-SAS verification MSC was approved just recently, and it was supported in Element since the beginning of E2EE and the like
Jonathan (@jboi:jboi.nl) so the defacto state doesn't entirely match the dejure state, i agree, but it's a mess to clean up, and its slowly getting better
Jonathan (@jboi:jboi.nl) i'd say to think of all of the current things that're "as a MSC" but also "in production" (in element products proper) as a grandparented problem that the team now has time to focus on
Jonathan (@jboi:jboi.nl) the overall suggestion is to use unstable identifiers for everything, until something is properly stablized, so that stuff like communities (which never got properly added to the spec, and was only a mess) don't happen again
Jonathan (@jboi:jboi.nl) rn all space-related things are still unstable, the main core spaces-related MSC, 1772 (iirc), is slowly "actually" landing, and i think it'll land before Element pulls the trigger on properly releasing it
Jonathan (@jboi:jboi.nl) which'll mark a moment of maturity, imo, which is a good thing
Jonathan (@jboi:jboi.nl) not that the spec is unfrozen, the SCT will gain a lot of traction properly landing all of this, and hashing out all of the problems and make a clean proposal out of it's intrinsics
Jonathan (@jboi:jboi.nl) (and yes, this should've been in #matrix-spec:matrix.org 😅)
Asbjørn okay so I understand that:- the spec change process values working real-world implementations
- generally speaking, element won't release MSCs into the ecosystem, but keep un-merged features behind an "experimental" feature flag
- reactions and edits are in the mainstream ecosystem despite not being in the spec, because the matrix team was "moving fast and breaking things" in the early days.
- I should join #matrix-spec:matrix.org 😉
Jonathan (@jboi:jboi.nl) yes, there's a lot of inherited debt that now is slowly being cleaned up
Asbjørn it's comforting to know that reactions and edits are exceptions to the rule. it seems like they're doing it right with spaces. I'm hopeful in knowing that the matrix.org / element teams are trying to not put non-spec features into the mainstream ecosystem
Jonathan (@jboi:jboi.nl) ^ my main point
Jonathan (@jboi:jboi.nl) yeah, the problem is the current state, not the current behaviour of the teams
Jonathan (@jboi:jboi.nl) i was very vocal about this mess when i first looked at matrix, but rn im convinced it is "okay", it is slowly being worked away
Jonathan (@jboi:jboi.nl) if anything, i'd be impatient, but i try to re-route that into contributions and pointers instead, so i can help get this moved further along
Jonathan (@jboi:jboi.nl) in fact, if you want, you could give a look at the reactions/relations MSC, i heard it has some problems/unresolved issues which is causing it to stop rn
Jonathan (@jboi:jboi.nl) (i heard this mainly from tulir recently, so its afaik)
Asbjørn I think it might have been me asking a question about that In matrix hq earlier 🙂
Asbjørn * I think it might have been me asking a question about that in matrix hq earlier 🙂
tulir > <@jboi:jboi.nl> in fact, if you want, you could give a look at the reactions/relations MSC, i heard it has some problems/unresolved issues which is causing it to stop rn
well adding more comments doesn't exactly resolve the issues :D
tulir someone from matrix.org has to dive in and sort out the mess (figure out what everyone is complaining about, decide on how to solve them, update the MSCs and get the SCT to review them)
tulir but nobody wants to do that because everyone is complaining about different things and it's a mess
TravisR that shepherd is most likely going to have to work with the SCT and wider ecosystem as a whole, so unfortunately is something that falls to someone from the SCT to deal with
FarooqKZ > <@tulir:maunium.net> depends on the platform, how would the push notifications go to your app?
Mozilla's simple push API which uses HTTP. See https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/Simple_Push_API
FarooqKZ > <@x:riot.ovh> the push gateway translates a matrix push notification to whatever push mechanism you want to use, e.g FCM, GCM, APNS
it also means that the matrix client and matrix server don't need to share a push keypair, as the push gateway is associated with the client instead, offering much greater flexibility
yeah this offers flexibility but I have to write a server software and maintain it for my client. For now I guess Python + CherryPy would be my best bet as I can quickly write the server software. Then I can migrate to something like Rust over time.