Come Help: List of FEPs Needed

ActivityPub Fediverse Enhancement Proposals
#1

Building off @pukkamustard’s FEP and the initial proposed process over at https://git.activitypub.dev, there’s a list of FEPs that are missing that could document the current Fediverse better:

  • webfinger: @tinyrabbit + ?
  • http signatures: ?
  • federating Block activities: ?
  • custom emojis: ?
  • e2e encryption: ?
  • nodeinfo2: ?
  • federating.md: @darius
  • chat: @lain
  • …?

(I am not here to say which of these I do/don’t endorse, just figured all should be considered for FEP)

I’ve “volunteered” a few folks I think that had expressed something before. If I’m wrong, let me know. :slight_smile:

Anyone else want to sign up / pair up for writing these? Also, what other topics are we missing?

2020-12-11 SocialCG Meeting
2020-12-04 SocialCG Meeting
Go-Fed Work Tracker Megathread
2021-01-09 SocialCG Meeting - FEP
#2

Since I just implemented webfinger I could co-write that with someone more experienced.

#3

Since I just finished adding NodeInfo2 to apcore I’m happy to write up the current state as a FEP.

EDIT: That FEP is now written. I’ll create a dedicated feedback thread once it is merged in.

That leaves the following:

  • webfinger
  • http signatures
  • federating Block activities
  • custom emojis
  • e2e encryption
  • federating.md
  • chat
#4

I wonder if there should also be a FEP detailing best-practices on how to deal with Linked Data?

#5

I’ll try at least some of these.

  • unambiguous capability negotiation/announcement
    • privacy settings can be included in that — you can do X to this user but only if they follow you
  • wall posts
  • groups, especially membership
  • cross-instance data consistency, probably just document what I’ve been doing in Smithereen with LD-signed activity forwarding for a while already
2 Likes
#6

Remote interactions (Follow, Reply, Share…)

#7

So this is more of a heads up…

A new FEP that will need to be written in the future, depending on how standardization goes: OAuth2 Rich Authorization Requests (aka “OAuth2 dynamic scopes”). It is a possible solution for the category of problem exemplified "@jessie@foo.example.com visits bar.example.com and wants to boost a post they’re viewing on bar.example.com". That particular example may be contrived, so I wouldn’t get stuck on it specifically, there’s a lot other interactions one could dream up where this is helpful.

Where the FEP comes in is: these Rich Authorizations are going to need… you guessed it… community-managed ontology/understanding.

Then, I’m sure lots more FEPs will come about as different software projects want to provide peers’ users a near-first-party kind of experiences, where it makes sense, if it makes sense to (as compatibility is once again showing it is the foundational problem).

1 Like
#8

Once thing that I would especially like to see is full migration capability across the Fediverse (or at least between all platforms where it makes sense).
Because Fediverse aims at empowering users, enabling them to choose their home instance and change it, I feel an additional step would be to enable users to test and change platforms, moving from Pleroma to Mastodon, to Misskey, and back.

It seems to me (but maybe I’m being naive), that such a possibility is not a major hurdle and would “simply” require:

  • to decide upon a list of platforms that can be made interoperable (Masto, Pleroma, Friendica, Hubzilla, Zap, Pixelfed… others?)
  • come up with a list of common features that exist on all platforms (username, bio, followers, follow, block…) and agree on a standard import/export format
  • implement a generic moved-to/moved-from mechanism that builds on existing implementations in Mastodon, Pleroma, and Zap (at least I know they provide something along those lines)

To the best of my knowledge, this does not currently work though there have been some effort within the Pleroma community but I think that was for full servers (see this issue), though I heard about people investigating single user migration, I did not find any information about that.

1 Like
#9

From the original issue queue:

It is one of the most asked for features by Mastodon users, which Eugene wants standardized before implementing.

Working in the CMS space with WordPress I am also keen to implement this in a standard way, as wp already has native Comment Policy options.

EDIT: Thanks for pointing out the problem with advisory flags @nightpool, going back over the original issue it appears that this is where OCAPs would come into play.

#10

Yes, the idea of a advisory flag is not a new one, it was discussed on the thread you linked. it has a major problem though: If I (on cybre.space) reply to Gargron’s “followers replies only” post (on mastodon.social) and send it to all of my followers, and he doesn’t allow my reply, all of my followers on mastodon.online, glitch.social, and every other instance will still display it, right underneath Gargron’s post (because they have no way of knowing whether I’m allowed to reply or not).

From an anti-harrassment perspective, this is regarded by many, many users we’ve talked to as worse then not having the setting at all.

A software I know of that gets this right is Diaspora, but they do this by requiring that all replies are federated out the instance of the original post, rather then the post author

2 Likes
#11

In Smithereen, I do it the same way as Diaspora. I only send the reply to the authors of the top-level post and the reply that’s being replied to, if any. The server of the author of the top-level post is then supposed to forward it to everyone who might have the thread.

1 Like