Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    matrixbot
    @matrixbot
    vahid_nadarkhani Is there an api that can be used by the widget to tell the element to get access token of user which it is currently logged in?
    for get user rooms list, or ect ...
    matrixbot
    @matrixbot
    Michael (t3chguy) no, you cannot get the access tokens
    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.
    matrixbot
    @matrixbot

    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

    matrixbot
    @matrixbot
    tilde An MSC pretty much requires a real-world implementation before to show that it's feasible before it can be merged anyway, so it's unavoidable that features will be implemented in the "real world" before getting merged into the spec

    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
    matrixbot
    @matrixbot
    Jonathan (@jboi:jboi.nl) this is an artifact from when matrix literally had to do anything to survive for 4 years, where concern to coherency on this level was second-hand, so to speak
    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 😅)
    matrixbot
    @matrixbot
    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
    matrixbot
    @matrixbot
    TravisR yea, that particular MSC is not one which needs more community involvement. The opinions have all been raised, now it needs a shepherd to fix it
    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
    matrixbot
    @matrixbot

    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.