Should we produce a specification-track document for interaction controls? #152
Replies: 3 comments 9 replies
|
Earlier this year I initiated a grassroots effort to write a spec based on GoToSocial's Interaction Controls. We were going to do the FEP process, but the work stalled due to limited bandwidth on my end and a lack of active contributors. I got the impression that a lot of people, including several implementers, are basically waiting for a solid spec. I engaged pretty deeply with the GTS proposal and (I dare say) I have some ideas on gaps that need to be filled and design questions that need to be decided to make it usable for the wider fediverse. I also think, assuming the question of licensing can be resolved for the GTS text, a lot of the writing I did on top of it could be reused here. I'm not currently a member of the WG or the CG, but I'd be enthusiastic about contributing to this if the above sounds useful. For now I've noted down the next task force meeting in my calendar. |
|
I'm interested in participating in this, as the author of the GtS interaction controls stuff. I'll be at the interim task force meeting on August 19 :) |
|
I have implemented with some testing this week the 044f document, with some qwirks in wafrn. I am not good at writing technical documents, but I would like to tackle this somehow because we are kinda doing this with some changes already already: Because wafrn does stuff with other decentralised networks too, we needed an extra option, "sameAsInitialPost". There are also "social reasons" for this. Basicaly: if a post is automaticaproval/manualaproval and has "sameAsInitialPost" as a value (as a made up list by me), the application must apply the same interaction controls as compared to the initial post. When asking for authorisation, we need to request the accept to the op of the post, not to the person we are replying to. I will provide examples later if that's ok |
|
Conceptually that would be great. In practice the GTS docs recommend against it because if an interaction by an actor on server A with an object hosted on server B depends on a permitted collection on server C, the implementation gets very expensive or prone to inconsistencies or both. |
|
I would add a "rootPostId" property, to not have to do a recursive query and make it easier on other software |
|
I have a page or two in my draft text on how interaction controls relate to context management, after hashing out some ideas with Julian Lam. We can take a look during the meeting next week if you want. |
|
https://w3id.org/fep/7888 and https://w3id.org/fep/2931 are the relevant FEPs for as:context and it being a as:Collection. It doesn't point to the "root post" per se, but you can still reason about context.attributedTo in a similar way as you might reason about .attributedTo right now. The full social implications surrounding "context" are not universally agreed upon, but you might consider some of the following:
|
Uh oh!
There was an error while loading. Please reload this page.
We currently have issue #10, which was intended to just be a single paragraph non-normative section in a Note document for the initial report.
The ecosystem has moved on substantially from the time at which that issue was written, so now I'm wanting to seek input on whether we prepare a standards-track document for interaction controls which would be following the WG/CG Stage Process to lift things up from being FEPs to CG Reports and then with the goal of Working Group adoption.
The following FEPs and documents are relevant here:
On that last one, we need to figure out whether we can under the license that covers that document.
All reactions