Cross-posting within ActivityPub
Technical Discussion
4
Posts
4
Posters
11
Views
-
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
-
@mariusor I agree that finding those last percents of coverage can be a pain.
But yes, more so trying to get a full app coverage up is hard and unsatisfactory work.
-
I forgot how tedious it is to chase code coverage when writing tests.
However this was part of the reason that made me include the "boring" parts of building a robust library into the goals set for the #nlnet grant.
So after a couple of days of work I finally got the first of the storage backends for the #GoActivityPub library go past 80% test coverage.
I hope I can reuse some of the test logic in the other backends, as they need to perform identically.
-
@silverpill @helge@mymath.rocks @helge@mastodon.social @julian can y'all copy me out — I just CC'd Julian as lead on forums taskforce, I don't personally care that much
-
>"Who can create topics?" with possible values being "Everyone", "Followers", or "Moderators".
I am noticing that each value here is a collection.
For the property name, I'd use the canDo convention that is already used by some Fediverse platforms:
{ "canCreateThread": "<collection-id>" }
-
helge@mymath.rocks yes, you're right. Piefed does, but also WordPress, so there's already some buy-in from implementors.
So I'd recommend that any guidance include this usage as well.
-
I guess piefed has postingRestrictedToMods to restrict posting using a boolean flag.
I have already voiced my dislike for all these boolean flags a few times. Would it be possible to have in addition an informative property value? E.g. "Who can create topics?" with possible values being "Everyone", "Followers", or "Moderators".
This would fit well with the mechanism proposed in FEP-19b3: Specifying Properties of a Service. It would also ensure that the information is visible to most people. Meaning increased interoperability.
-
... but importantly, this also might not mean the forum itself allows remote content creation, so you have to check for a boolean bit in the actor that allows for it... or its omission.
That last part is as yet undefined in an FEP.
helge@mastodon.social silverpill@mitra.social thisismissem@hachyderm.io
-
thisismissem@hachyderm.io thanks for the ping.
helge@mymath.rocks there is a very specific condition... You can only assume a topic was added to a community/category/forum if it was addressed to a group actor on your instance (because you control the content ingestion) or if the group actor itself announces it.
Otherwise it's membership state is only a guess. You can explicitly signal intent to post to a community/category by putting the group actor in audience.
