Following up on this question I asked back in late March, I wanted to continue thinking about how one would handle cross-posting between categories/communities, given that there isn't current consensus on it, and especially given that NodeBB—as of v4.3.0—can now see and browse remote categories.

From that original topic, we can distil the following:

1. Both PieFed and Mbin do not natively handle cross-posts, a new entity is made with the crucial bits (link, text, possibly title) copied over and changed if needed, sometimes a "cross-posted from..." helper text is prepended.
2. There are legitimate concerns that a cross-post might not succeed depending on privilege settings on the receiving end, so a pre-flight check (or explicit rejection) of some kind might be required.
3. Cross-posting can be done by the original author, or another user.

So were an FEP to be written, we'd center it around the following assumptions:

• "A user (which may or may not be the object author) is sharing an object to additional audiences"
• We would use the existing Announce(Object) model
• We would not use Announce(Activity) because it is not the original object creation that is being announced, but the object itself, to a new audience.
• Some form of Reject handling would be required for cases where the cross-post is not allowed
• How the receiver handles the activity is out-of-scope of the FEP. It could be that the original object is contained within multiple categories/communities, or a duplicate object could be created — implementor's choice.

This is very similar to an existing announce/boost/reshare, except that instead of addressing the activity to followers list you are addressing it to a group actor's inbox.

Some additional questions:

1. Is there desire from PieFed/Lemmy/Mbin for supporting incoming (and possibly outgoing) federation of cross-posting?
2. What exactly happens currently if a Group actor receives an Announce(Object)? My guess is nothing, currently, but let me know otherwise :smile:
3. Would this allow you to accept cross-posts from other AP applications without needing to refactor any existing code?
4. Duplicating the object would mean the discussion is split between objects. The ideal implementation would be the same object present in multiple categories/communities. Is there desire for this in the threadiverse?

@rimu@piefed.social @andrew_s@piefed.social @melroy@kbin.melroy.org @bentigorlich@gehirneimer.de @nutomic@lemmy.ml @angusmcleod@mastodon.social

Whenever I participated on social media platforms in the past, key functionality seemed to be unavailable. In some cases, functionality I consider to be important just might not be that useful for most other people – but in other cases, functionality that is useful would actually be detrimental to some bottom line the company considers more important than its users, and thus doesn’t get implemented.

As just one example, I consider it to be useful for the accounts I follow, as well as those that follow me, to be checked for their activity regularly, and unfollowed automatically if they are indeed inactive – because talking into a void just isn’t fun. Follower counts are an important metric for influencer-type people and the platforms that want to attract and host them, which likely is why, as far as I am aware, none of the commercial platforms offer this functionality.

What if managing the accounts you follow was as easy as this?
Mastodon, however, is not a commercial platform. It is an open-source, decentralized microblogging service roughly similar to the now defunct Twitter – and it has an open API allowing functionality to be added by third-party developers via their own client apps.

I consider Altamira to be an experimental companion app for Mastodon. “Companion” because my plan is not to build yet another full-fledged Mastodon client, but just something that is used in the background, in addition to whatever client app might work best for someone – and “experimental” because while I have a general idea about the kind of functionality I’d like to see, individual details often need some trial and error, and are very much up for discussion.

I will try to talk about functionality implemented in the app every now and then, so feel free to follow to come along for the ride.

For a lot of things in ActivityPub, there are almost direct parallels in NodeBB. An as:Note object pairs well with a NodeBB post, an as:Person is a NodeBB user, etc.

One thing that didn't map 1:1 was the Delete activity, which at surface level, seems rather straightforward — just delete the object! However, once you dig in, there are some additional considerations:

• in NodeBB, we have two separate states for content removal.
  
  • A delete, where the post is still present (but its content unavailable to non-privileged users), and a
  • A purge, where the post is scrubbed from the database entirely, and all references to it, removed

  
  

• in ActivityPub, there is a single activity, as:Delete
• Implementors may opt to replace the object representation with an as:Tombstone (how quaint!), but they may also just opt to use a 404

So there are some nuances that are left intentionally vague.

Kaniini on SocialHub makes the argument that a Delete should be treated like a cache invalidation, which has its own merits.

This is how NodeBB will interpret the protocol specification, and how we will align it with our own dual-state post deletion mechanic (delete & purge):

1. When a local post is deleted, we will federate out an Update(Tombstone) referencing the id
2. Afterwards, if the content is retrieved, an as:Tombstone will be served.
   
   • Deleted posts in NodeBB still maintain their place in the topic, so when the context is retrieved, the note will still be present in the collection.

   
   

3. If we receive an Update(Tombstone), we will delete the local representation of the post
4. When a local post is purged, we will federate out a Delete(Note)
5. Afterwards, if the content is retrieved, we will serve a 404
   
   • The note will no longer exist in the context collection

   
   

6. If we receive a Delete(Note) (or Article, or Question, etc.) we will not delete it immediately. Instead, as kaniini advises, we will attempt to retrieve the object from the origin:
   
   • If we see an as:Tombstone, we will delete the post (soft delete)
   • If we encounter a 404 or 410, we will purge the post (hard delete)

   
   

I'm writing this out less as a guideline for myself, but to solicit opinions and to give others a chance to point out if I've interpreted the spec incorrectly.