Prioritizing key #FEP's Ahead of Thread's Federation

Hi all: I’ve been looking at what features Mastodon (and other Fediverse platforms) have been considering that could do the following:

  1. Be implemented within the 2 to 3 month time frame
  2. Signficiantly and strategically help Fediverse admins manage and moderate content better
  3. Need no, or quick FEP work to be at a mature enough space that developers feel safe creating early versions of them into their software

See this list: (and welcome what everyone thinks of this effort)

1 Like

Could we just wikify this topic and ditch Google docs? :wink: Makes this whole thing more searchable too.

While somewhat of a secondary concern, I would add Nomadic Identity as an important protection vector.

https://thenewstack.io/threads-adopting-activitypub-makes-sense-but-wont-be-easy/

ActivityPub perfectly suits Meta’s goals, I suspect, and here’s why:

With ActivityPub, the server manages your identity and data. So when you join Mastodon, for example, you are essentially entrusting management of your data to the server (“instance”) you join. As fediverse developer Ryan Barrett put it in a post this week, your ActivityPub “identity, data, and administration are all tied to your instance, for both technical and cultural reasons.” Among other things, this architecture enables your instance to make moderation decisions on your behalf. You’re still free to move to another instance, at any time and for whatever reason, but you can’t port your data (your posts and media) from one instance to another.

I mention all this because it plays right into Meta’s strengths. Meta will still control the identity layer even when it integrates with ActivityPub — and that’s immensely valuable when you’re the owner of Instagram’s social graph. Since Threads is also hosted on Meta’s servers, all your data is managed by Meta too.

There’s no way Meta would’ve wanted to join the AT Protocol or Solid, because in both cases they would potentially be handing over control of identity and at least some data to their users. As Barrett put it in a separate post: “One core difference between the fediverse and the AT Protocol seems to be that AT decouples many key building blocks — identity, moderation, ranking algorithms, even your own data to some degree — from your server.”

Threads will not be compelled to implement nomad-id, but as long as it exists in alternative AP instances it applies pressure.

2 Likes

+1 to wiki-fying / pulling in those items into here at least.

I also highly agree that Account Portability / Nomadic Identity / Export feature (and I know there’s some overlap with all three) would be incredibly important in the Fediverse’s relationship with Meta. Possibly the most important feature, honestly.

I propose that we approach this from two directions:

  1. Lobby Threads to commit to providing Export functionality (specifically, exporting the profile, social graph, and posts), as well as supporting any relevant redirects (“this user has moved over there”…).
  2. Focus on getting Export/Import/portability working on as many implementations in the Fediverse as possible, as a leverage for the above (and to set a good example).
3 Likes

That seems strategic to me. Would that be something that could be done in this timeframe?

“Be implemented within the 2 to 3 month time frame…Need no, or quick FEP work to be at a mature enough space that developers feel safe creating early versions of them into their software…”

Will do, not used that before, is this that service? https://www.wikify.com/. Just signed up for its beta.

Oh, I just assumed it was a general verb of “throw it on a wiki somewhere”. Or start a Discourse thread on here, with it.

Right, definitely the right question to ask here. I think it could be done in 2-3 months timeframe.
The lobbying part is “easy” (started here, for example), the hard part is - will Meta be swayed.

The implementation part - I do think it’s doable, I think we have all (well, most) of the FEP pieces, and I’ll be jumping into the implementation part shortly.

1 Like

I am willing to be of any help I can to organize and rally any troops to get these and other priorities that feel strategic as far down field as we can.

1 Like

If you give me the relevant FEP’s I’ll add them to the google doc, and later will move it over to a Wiki format.

Oh right. So, there’s a lot of discussion over at the Account Migration and Nomadic identity for the fediverse? threads, but I’ll see if I can summarize / provide FEP links.

2 Likes

great list so far, love to see it

1 Like

It’s a Discourse feature you can enable on your topic to let others edit it (with edit history in case you need to revert a change). Might need @moderators to enable it.

3 Likes

I created a Wiki for this subject. Keep this thread for discussion. The wiki topic is closed so edits will keep bumping it to the top of the topics list.

@tchambers could you edit a link to the wiki in your top-level post?
@how could you reassign the wiki to system user?

This a great list and collecting things is always good :clap:

From a technical visionary standpoint (scnr), I would like to see something akin to:

  • Format for servers to advertise functionality. This would mean specifying a new endpoint, e.g. .well-known/fediverse that pubishes a document in the form of
{
  "features": [
   {
    "name": "fep-521a",
    "href": "https://codeberg.org/fediverse/fep/src/commit/eb33a705a207ec0b94f9195172a62ae783ed635e/fep/521a/fep-521a.md",
    "status": "full",
    "testStuide": [
       "https://codeberg.org/helge/fediverse-features/src/commit/b9bf8833ab003f1c111881037e8e5c75bdea0cac/feps/fep-8b32.feature",
       "https://codeberg.org/bovine/bovine/test-runner $TESTSUITE"
     ]
    }
  ]
}

where the exact format needs to be specified. In particular, the “status” and “testSuite”.

The motivation would be to get implementers to have some understanding of what supports what without having to play the “test it out” and “read code” games.

1 Like

My recommendation was to simply wikify the top post of this topic, so we can keep all the discussion in one place and @tchambers can carry on with the responsibility of lead curator.

I don’t see what we’re gaining by separating out the wiki topic.

Content licensing seems relevant. If not a hard protection, it’s at the very least a form of activism by giving me a way to explicitly say my content is not allowed for use in day farms, closed AI etc.

Too big a topic.

Similarly for Account Migration / Nomadic Identity.

Subscribable User Blocklist
https://github.com/mastodon/mastodon/issues/116

:+1: Can probably be realised as a service independent from Mastodon. Flow would be:

Setting to limit replies on your posts:
Enable Twitter-style Reply Controls on a Per-Toot Basis · Issue #14762 · mastodon/mastodon · GitHub

I commented on this in Matrix:

I think a good analogy for “reply control” is quote posts. It’s easy to implement quote posts in a client. So people have done it.
Comment control on apps is kind of “nasty” as it wouldn’t work across different apps.
People seem to lack the imagination necessary to just use a “#DonTComment” hashtag in the base post to indicate that comments should not be displayed.
This would work nicely across apps and not require any slow Mastodon changes.
I’m probably an awful person for suggesting the quick fix. The ActivityPub tech stack is just not ready for hard soluitons.

Also note that I think #NoReply is superior to #DonTComment. This is a dirty solution, in the sense that it adds technical debt. However, it is a solution that can be implemented without creating too much technical debt. It is clear that this is a “hack” of a “hack”, i.e. hashtags, and thus should be removed once better solutions are available.

1 Like

The gain is that edits to the wiki get noticed, because they bump the wiki to the top. Whereas otherwise they don’t and this thread sinks in the list until a new post is added to the discussion.

2 Likes

Am getting Wikify rights soon, when I do will rewrite the original post in WIki form.

Exactly: to get focus one these collective set of potential additions - that all solve for one very big use case of being a tighter ship for when Threads federates in with what I assume by that point will be 300 million users or more by that point - many of whom will be moderation issues. How to prevent abuse, how to empower users to fortify their own accounts and how to give admins a few more tools in the toolbox.