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

ActivityPub
3

+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
4

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…”

5

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

6

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.

7

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
8

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
9

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.

10

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
11

great list so far, love to see it

1 Like
12

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
13

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?

15

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
16

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.

17

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.

18

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
19

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
20

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

21

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.

22

I’m somewhat relieved that we MAY have more like 4 months to get these priories out the door…I wouldn’t assume more, just in case.

Screenshot 2023-07-14 at 2.23.40 PM
Screenshot 2023-07-14 at 2.23.40 PM1182×1284 142 KB

1 Like
23

I’m no moderator or AP developer but I do have a (not currently specified, to my knowledge) suggestion I’d like to throw out there as it relates to moderation:

The ability to limit new users from a remote instance could allow certain Threads users to interact with an instance, while automatically keeping out everyone else. It could also be useful during remote instance spam attacks, to allow existing people to continue interacting as normal while keeping out the wave of spam accounts.

  • I don’t think this should be a “deny” but rather an “ignore,” so that once the spam attack is over, legitimate users who registered during the attack can interact once the limitation is removed.
  • Admins should be able to manually approve new users even if the setting is on.
  • In Mastodon, I think this would be best done as a check-box next to the existing “limit/mark media” options, so that you can combine it with “silence” for some servers and “none” for others (to allow existing users to still appear in public timelines).
  • This might be useful for firehose bridges, especially if some pattern matching can be added (i.e. by domain suffix), like mostr.pub and the future Bluesky bridge(s).
1 Like