Cross-posting within ActivityPub
-
Just wrapped up a session at FediForum where snarfed.org@fed.brid.gy and quillmatiq@mastodon.social discussed FEP-fffd: Proxy Objects as a way to link disparate cross-network objects together.
I piped up that rimu@piefed.social and I were working on similar problems with cross-posting, though we were discussing this well within the confines of ActivityPub — cross-posting between threadiverse communities
We hadn't come up with any path forward yet, but the FEP notes some properties that we could use.
alsoKnownAsto refer to a canonical post?- An
urlarray to show cross-posts?
-
@julian @snarfed.org @quillmatiq @rimu This was above my pay grade. LOL but always fun listening to them and trying to figue out what the heck they are talking about!
-
I wouldn't use
alsoKnownAssince that's typically for Actors and "people", however you may want to look at the RDFsameAsproperty or something from a similar RDF space. -
@julian @snarfed.org @quillmatiq @rimu this is at the forefront of exciting fedi dev and I can't wait to see where this leads!
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian @snarfed.org @quillmatiq @rimu this is at the forefront of exciting fedi dev and I can't wait to see where this leads!
-
Well, the whole idea behind them being resolvable is so that when they are acted upon (by the context owner), they can be queried.
For example if I receive a Delete(Context), I'll resolve it to find the root level post, and from there find my local representation, and delete it, assuming the actor was allowed to delete it.
They're only server generated views per current usage... but why do they have to be constrained to that usage?
-
Delete(Context)? This is very unusual because other collections are not created or deleted, they are server-generated views.
I assume this problem arises when you create a topic for a remote post? Perhaps deletion of such topics shouldn't be federated?
Or you can generate
Announce(Remove(object: root, target: Context))It would be valid from the authorization point of view.
-
@blainsmith @rimu @jwildeboer there is a forthcoming FEP from the AP T&S taskforce that introduces the idea of a Moderation Actor for Actors, so like "Moderated By", which would be a Group or Service actor probably, but it would not be required to disclose it's members.
-
@thisismissem@hachyderm.io
Good call out! This could either kill the idea or one possibility would be to make this opt-in, but @rimu@piefed.social does raise a point about moderating communities with instances.
@jwildeboer@social.wildeboer.net
-
@rimu @blainsmith @jwildeboer There's a potential danger in this, in that it would allow bad actors to specifically target instances which maybe don't have enough moderators, allowing undesirable behavior to go unchecked
-
On many platforms you can make an activitypub request to / which returns an Application actor and would be more appropriate, IMO.
Although, in the threadiverse most mods only moderate their communities, not the whole instance.
-
I wouldn't use alsoKnownAs since that's typically for Actors and "people", however you may want to look at the RDF sameAs property or something from a similar RDF space.
