Announcing a new Fediverse Enhancement Proposal for your review:

"FEP-e232 is a proposal for representing text-based links to ActivityPub objects using tags"

Learn more and discuss at and

· · Web · 4 · 9 · 8

hell yeah, gimme that @jonny:namespace:object reference and #.namespace:object anchor microsyntaxes

@weex oh thanks for posting! I have been following this topic for years its awesome to see someone trying to standardize it!

We had some disagreement over whether it should be an attachment or a tag; but that's not a hill I intend to die on and one person was willing to die on that hill; insisting it should be a tag because it wasn't "included" in the body but only linked by reference. We actually include it in the body; which means attachment is more appropriate and is the correct answer for our use case. In any case we currently support 10 different quoteUrl mechanisms, but we might be able to whittle that down to 2 at some point.

@mike i should clarify the reason i was/am willing to "die on the hill" is specifically for misskey's usage, and specifically because of the quote's inclusion in `content` as `RE: url`, that `tag` is more appropriate. if your project(s) treat quotes as something extra and not part of the content, then `attachment` is suitably fine for this usage. so i suppose that yes, we would be left with 2 mechanisms. or possibly 4, if someone wants to not use Links but rather Notes/etc. such is activitypub.

No worries. I have no argument or disagreement with your usage, and the FEP is correct for the way you are using it.

I've mentioned before we don't treat the quoted message as something extra - we "embed" it verbatim inside the content. We don't put a reference to it - we include the entire content. The attachment is only there for Mastodon and other microblogs that strip out basic HTML and might remove the embedded content as they do for images and videos. In this way viewers will find the link to the post in their attachment list and can visit it directly if the embedded content was removed for some silly reason. If your platform displays HTML content just fine you'll never have to care that this mechanism exists. I'm happy to support the FEP. But I also have to work within Mastodon's interpretation of the fediverse as a plaintext medium with attachments and our interpretation of it as an HTML rich media communication stream per the specification.

@mike would it be more or less useful to consider it as using `tag` for metadata? i am thinking it would be better to refocus the FEP around "this Link should be fetched as an Object" and accordingly proposed using rel instead of mediaType.

as far as "plaintext" vs "html" goes, i am interested in having a clear mechanism for replacing substrings of content with rich links to some other status / profile / emoji. this should be useful for both worlds. i'd also like to see direct tags of object id

@mike in other words, "how do i know that this anchor's href is supposed to be an activitypub object?"

currently there's some nonstandard expectations such as mastodon expecting a class of "mention" for its HTML sanitizer. i think they also parse tag for Mention links in order to generate notifications, instead of using the native to/cc addressing.

misskey basically invented the quoteURI and _misskey_quote properties purely to know when an activitypub object is being linked or referred to.

"how do i know that this anchor's href is supposed to be an activitypub object?"

You don't. It might be a Diaspora object. It might be a Nomad object. It might come from the New York Times or the Detroit Free Press. There's every possibility you won't be able to fetch it even if you know what it is because there may be permissions or paywalls involved.

That's why we include the content so you don't have to figure it out.

@weex So, basically something like "quote retweets"? This is cool, I really wanted this to happen. I think there are a few AP implementations that already do this (Friendica and MissKey), but I hope that this feature will be standardize soon enough.

@junbird @weex that is one possible application, yes. the way i see it, the FEP is for defining how to link to objects with a microsyntax (the microsyntax itself is out of scope).

so you can already have the following:

- tag a Mention (microsyntax: @)
- tag a Hashtag (microsyntax: #)

the FEP is proposing the following

- tag a Link (possible microsyntax: RE:)

@junbird @weex for example, with what misskey does, they use RE: URL and just replace that with an embedded preview pretty much.

with this FEP, misskey can define that RE: URL as an object link microsyntax. other projects can parse for tag of Link and understand that a reference is being made.

"then how would you know whether you can dereference that link as an internal reference rather than just some ordinary link?"

That's why we provide a link as an attachment for projects that remove the HTML content. There's no guarantee you can dereference it, but we'll provide it in case your platform strips HTML and maybe, just maybe you can fetch it instead of staring at a blank Note. Maybe you can't.

I think we're just going in circles now. I already mentioned I don't have any desire to die defending this hill. My software is different from yours and does things yours does not. Your software is different than mine and does things that mine does not. We're not trying to make every platform behave identically, because we actually can't. We're only trying to make them work together as seamlessly as possible. The FEP is a huge step in that direction and I applaud it and support it.  So let's just accept that and move forward.  You don't have to support objects as attachments if you don't want to. I'll put in some effort to make them look like FEP-e232 so your software and any other project that supports FEP-e232 will be happy either way. This work is not yet completed. Apologies.
Sign in to participate in the conversation
Ecko /

Creating magic through evolution of the Fediverse. Running Ecko, a community-driven fork of Mastodon managed using the Collective Code Construction Contract (C4) by the Magic Stone Community. C4 is a protocol for asynchronous, non-blocking, distributed, problem-focused software development.