FEP-f15d: Context Relocation and Removal
Technical Discussion
6
Posts
2
Posters
36
Views
-
Threaded applications often have the need to move and remove content between groups/communities for curation purposes (i.e. resolving miscategorization, spam, etc.)
This is an extension of the Resolvable Contexts tree of FEPs.
The FEP draft has been submitted for review. In the meantime, it can be viewed here: https://github.com/julianlam/feps/blob/fep-f15d/fep/f15d/fep-f15d.md
-
The submission of the FEP and timing of this post are intentional as there are now two implementors supporting (part of) this FEP.
- NodeBB as of v4.7.0
- Piefed as of v1.5
As the implementors work through any issues, the FEP and this topic will be updated to reflect those changes.
-
The submission of the FEP and timing of this post are intentional as there are now two implementors supporting (part of) this FEP.
- NodeBB as of v4.7.0
- Piefed as of v1.5
As the implementors work through any issues, the FEP and this topic will be updated to reflect those changes.
Tagging relevant parties:
- @rimu@piefed.social of Piefed
- @nutomic@lemmy.ml of Lemmy
- @bentigorlich@gehirneimer.de and @melroy@kbin.melroy.org of Mbin
-
@bentigorlich@gehirneimer.de in the relevant issue in Mbin's issue tracker raises a wording concern: "resolvable context" is an unfamiliar term to those who have not read through FEP 7888.
I will update the FEP to make this definition more explicit.
https://github.com/MbinOrg/mbin/issues/248#issuecomment-3741019183
-
undefined oblomov@sociale.network shared this topic on
-
Hm, it appears that none of my objections have been addressed.
Once again, why there are two activities
MoveandRemove, and not a simpleUpdateor a new activity type? -
Hm, it appears that none of my objections have been addressed.
Once again, why there are two activities
MoveandRemove, and not a simpleUpdateor a new activity type?Hi @silverpill@mitra.social right;
MoveandRemoveare explicit actions concerning membership of a context in an audience.Updateis overly broad and receivers would have to infer audience change based on what the updated object contains (e.g. Audience Y is suddenly missing, and Z is new, was this always the case?)- It is likely that sending
audienceas an array will not be correctly interpreted by existing software, so this property is an unreliable indicator of context audience membership at best- Existing threadiverse apps check addresses, and
audiencemay not be used at all in some.
- Existing threadiverse apps check addresses, and
There is no conflict with
Move(Person), and I have not heard a convincing reason to adopt a new activity type when these two AS activities work quite well to describe what we want to accomplish.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Yes, I think I like the idea of clients being able to store data on the server however they like. It reminds me of this description of ATProto that I found recently: https://overreacted.io/a-social-filesystem/
I guess my question is: once I store my custom stuff in custom places on my server, how do I publish this so other people can find?
And, object IDs are usually defined by the server. So how would it work to say "create a collection named XYZ and add this object to it"?
-
@benpate @silverpill in a client managed followers collection i would Add you to my followers just like fedi instances currently do silently. "but how can you prove--" yes exactly, how can current fedi prove anyone is a follower either? you need the Follow+Accept pair to both be live without an Undo on either, right? and that's what leads to the "follow state machine" on fedi that drifts out of sync and leads to private posts being leaked to removed followers (which you can't officially do!)
-
@benpate @silverpill @mariusor none of the IDs should have any semantics; from the outside, there is no distinction between a client managed or server managed collection. likes/shares/etc could be managed by a "client" like mastodon, or even a "default" one. it's not any more complex unless you want to vary the collection responses based on the request headers. for that you need a minimal dynamic layer with an access control policy of some sort. (WAC is the simplest, but ACP is more powerful)
-
I e*love* this idea- especially in principle. I say that because I’m having a hard time wrapping my head around this and how it would be used in practice.
Do you think you could post an example workflow (or three) to demonstrate how this would work?
I get that objects could be added to client-defined collections (very cool) but if object/collection IDs don’t have predefined semantics, how will I know where to look to get the data I need?
-
> The thanks was for your input with regards to collection management.
@silverpill of course, sorry for the misunderstanding. Doubly so, for forgetting Mitra is Rust, I remembered it to be Python. :D
And yes, the difficulty is indeed in massaging JSON-LD documents into strongly typed data that are meaningful for library consumers. However I've not despaired yet... there's light at the end of that boring tunnel. :P
-
@julian It looks simple on the surface, but in reality it is much more complicated than a non-generic server. In addition to activity transfer, generic server needs to maintain collections. First of all, a followers collection, which is often used as a delivery target. Then likes, shares etc. It needs to enforce permissions, to prevent actors on the same server from deleting each other posts.
This is doable if you only care about activities defined in ActivityPub. But then you want to introduce context collection. And then 50 other extensions. How to do that without special-casing every one of them?
This is where duck typing (FEP-2277) and unified security model (FEP-fe34) become really handy. No matter what the client sends, you can figure out what it is (an object, an actor, or a collection), and enforce permissions.
-
@silverpill@mitra.social I find it curious that this needs to be spelled out in an FEP.
Isn't a generic AP server one that ingests anything and shoves it into the outbox... like a mail transfer agent?
... then delivers it dutifully?
I mean, sure, you can do stuff in between, like spam detection, blocklists, etc etc etc...
My quick read through of the FEP (and it was quick, because it was a short FEP :stuck_out_tongue:) seems to confirm this.
-
@silverpill lol, based on the "claims" at the begining, why do I feel like the "thanks" at the end should be in quotations?
Also I take umbrage with calling what I've been doing for the past 8 years as "being not difficult to build nor an interesting concept". I feel like you, and other developers having the benefit of dynamically typed programming languages, underestimate how that can be worked into robust APIs when you're limited by less versatile stacks.
