FEP-fffd: Proxy Objects

Standards Fediverse Enhancement Proposals
21

A new draft pull request is up! #99 - FEP-fffd: New draft using url and Link, plus merging instructions - fep - Codeberg.org

Full draft: fep/fep-fffd.md at 0c2bbbe6b157f052a1b3109354a7574e2d45058f - fep - Codeberg.org

Here’s the summary:

  • Proxy links are now Links in url with "rel": "alternate" or "rel": "canonical". The new @context entries have been removed entirely.
  • Protocols are determined by URI scheme and/or mediaType, not an explicit protocol URI.
  • Added ATProto, DID, Secure Scuttlebutt, RSS, Atom, and ActivityPub to the list of well-known protocols.
  • Specified that only bare NIP-19 identifiers can be used in Nostr URIs.
  • Added a section to explain the merging “algorithm”, mostly the situations in which merging breaks down and should be skipped.
  • Removed references to Zot, since no bridging is needed for Zot.
  • More clarity about which sections are normative.
  • Added a reference to proxies for moved ActivityPub posts, which seems like an ideal use case not considered before.
2 Likes
22

Aaaand it breaks Pleroma, because Pleroma validates that url entries are http/s. :melting_face:

This what what I was afraid would happen. My ideal fix is still to say that proxy links can be under either url or https://w3id.org/fep/fffd/proxy, and to say that url is recommended because semantics but proxy is more widely compatible.

1 Like
23

that is a bug that needs to be fixed in pleroma, then – first of all, anything not understood should be ignored, not stopping processing. this is in the spec. second of all, pleroma is clearly wrong to assume http/https here. it’s not the first time pleroma has been unnecessarily strict, tbh… same thing happened with e232 and having a Link in tag. pleroma expected all tags to be strictly one of Mention/Hashtag/Emoji.

broadly speaking, it is always more “compatible” to use a completely new extension property for literally everything, but hopefully it is clear why this would be a bad idea to do literally every time. it leads to a proliferation of extension props that overlap greatly with existing properties, and the only reason they exist is because some software somewhere had bugs that could be fixed.

1 Like
24

I created a Pleroma issue, we’ll see if it gets any traction:

Add a thumbs-up if you think this is the best approach, maybe that’ll give it more priority.

2 Likes
25

Just discovered this FEP, it’s awesome, thank you so much for creating it @arnelson! Love how simple and clear it’s ended up, using well established attributes like rel for canonical and alternate and not needing any new properties.

I should definitely adopt this in https://fed.brid.gy/ . It currently bridges web (via mf2 and webmention) and AP, I’m actively working on adding more protocols like you describe. Webmention isn’t in your list of example protocols, but it seems like it will fit fine.

Out of curiosity, are you aware of any consuming implementations yet?

3 Likes
26

Thanks! And Webmention was actually one of the protocols I was considering incorporating, but I couldn’t decide on a URI format. (Maybe plain URLs are enough?)

As far as I know there are no consuming implementations yet. I wrote this FEP because I wanted this feature in Tapir, which will probably be the first actual implementation of proxy merging.

1 Like
27

Yeah plain URLs are enough, webmention content is HTML over http/s with microformats2, and endpoint discovery is HTTP- and HTML-based, so no separate URI scheme.

https://brid.gy/ has been publishing mf2/webmention-enabled proxy pages for centralized social network objects for 11+y now, and https://fed.brid.gy/ for AP for 5+y, happy to compare notes if you ever want.

I’ve filed Add proxy links to AP objects via FEP-fffd · Issue #543 · snarfed/bridgy-fed · GitHub to track implementing this FEP in Bridgy Fed.

1 Like
28

Pleroma fixed their issue above! Might be time for more testing to see if array-valued and non-http url breaks anything else?

29

The fix probably hasn’t been included in any release yet. AFAIK Pleroma devs made several security releases during that time, but no feature releases.

30

Since then Pleroma had a feature release, but @helge’s tests suggest that array-valued url causes it to ignore entire object: Inputs Version 0.1.1 - Interoperability Data for the Fediverse

cc @lanodan

31

My impression from looking at the diff: CommonFields: Use BareUri for :url (!3884) · Merge requests · Pleroma / pleroma · GitLab is that the bug fix was allowing more url patterns, and not allowing the url property to be a list.

32

I think the Link objects, in combination with the hreflang property, are also useful for representing translation of other objects (cf. https://github.com/w3c/activitystreams/issues/463).

Yes, you can use the language map terms like contentMap to internationalize ActivityPub objects. But using separate objects has its own advantages:

  • Ability to attribute to the translator in addition to the original author (https://github.com/w3c/activitystreams/issues/463#issuecomment-1948970730)
  • Ability to indicate which language you are replying to (which is relevant if you are pointing out a typo in the post, for example)
  • Size efficiency for large articles
  • Ability to generate machine translations on an on-demand basis

(And the language maps are not quite widely supported by existing implementations. But you could argue that that’s also the problem of the implementations.)

To support this use case, I think the merging process of the proposal should take the user’s locale into account instead of recommending to unconditionally use the canonical object’s properties.

2 Likes
33

:100:

I like the example of

{
  "contentMap": {
      "en": ":catblob:",
      "de": ":katzenfleck:"
  },
  "tag": {
     "type": "Emoji",
     "nameMap": {
        "en": ":catblob:",
        "de": ":katzenfleck:"
     }
  }
}

to illustrate why using @language for internationalization causes havoc. You need to the above due to accessibility concerns.

Handling the contentMap, nameMap stuff would be possible if there was proper library support, but currently there is zilch.

1 Like