Does anyone know if there are guidelines for the Follow/Accept flow outside of that prescribed in the AP protocol?
The reason why I ask is because there seems to be a little logical hole that people fall into where a Follow activity is sent, but the relationship then rests in an indeterminate state:
The Follow is pending acceptance
The Follow was already seen and subsequently ignored
Something was wrong with the activity (e.g. signature failure, missing id, etc.) and it was ignored
Receipt of an Accept is asynchronous, so the approach as seen in the wild is to assume a "pending" follow state. The problem is that if the flow doesn't follow that happy path (instant-accept or pending), then you don't know there is a problem.
Furthermore it seems that there are no existing recommendations regarding handling of a Follow to an Actor who believes you are already following them. Do you send back an Accept? Ignore the activity?
I'm writing this because I'm unable to follow @weekinfediverse, but I don't actually know whether it failed or is pending accept.
While I firmly believe any errors would be on my end, the problem is I don't actually know for sure, and this would also potentially provide guidance for new implementors.
@julian@mike Hi Julian! We had an outage that is on its way to being resolved, though it may take a while for things to be all sorted. In the meantime, here's that coffee! ☕️
We've noticed in the past week that fairly innocuous looking posts are coming in from brand-new users containing spam links with no anchor text. They're caught by the post queue but at face value, they could be accepted by a moderator as the link themselves were hidden from view.
It was only once you inspected the raw post content that the hidden link was revealed (e.g. innocuous text [](//malicious.org).
To combat this, NodeBB will now explicitly expose hidden links so that they can be easily seen and caught.
If you are viewing this post from outside of NodeBB, you might not see anything! That means your software might be vulnerable to this kind of spam backlink injection. Best case, your software detects the empty link text and removes it completely. Worst case, you're allowing them in unknowingly.
Last thing, it's possible this has been around for ages and I only just noticed (thanks also to @pitaj for pointing out the hidden links from an earlier post!) If you browse around the forum and see some of these hidden links scattered around some posts, flag it immediately so we can take a look.
Sometimes we get spam. It's always caught by our post queue because we're a relatively small community and new registrants always get their submissions queued for approval.
Almost always it's obvious. Either it's just a plain ad, or tons of word salad... more recently it's AI generated crap which all sounds the same.
This week we're starting to see posts come on with innocuous content, like "me too" posts with slightly more content. What did surprise me was that they contained hidden links. Up until now I was seeing actual text hyperlinked, so they turned blue. With no actual anchor text, the anchor still exists, but is just invisible.
So I think a good next step here is replacing all links with empty anchors with a bright red hidden link element.
One of the action items that came out was to collate the state of current implementations. Unfortunately, outside of implementations that federate non-textual content (e.g. Pixelfed Stories, Mobilizon Events, etc.), the majority of implementors just use as:Note, which is not surprising given Mastodon's treatment of non-Note objects.
What is less clear is whether there is pent-up demand for use of a different data type for more richly forrmatted content. @mikedev and @jupiter_rowland provided some very illuminating history behind previous attempts to use as:Article, but importantly it seems that Mastodon (via @renchap) may be open to supporting this in some form as well.
While Mastodon has every reason to display as:Note as it sees fit, I'd like to hopefully address the undue influence towards using it especially in instances where as:Article were more appropriate. Mike (upthread) suggested a compromise:
that as:Note be reserved for content with attachments (images or otherwise), perhaps with a limited subset of html
and as:Article be used for content with a richer set of html (e.g. tables), and including the ability to display inline images
I explicitly did not specify that Note was for shorter content and Article for longer, because there exist plenty of examples of the reverse.
Does anybody see potential complications from such an arrangement?
I'll try to give it a boost from my #Mitra, #Hubzilla, and #Friendica accounts too (if I haven't already) so you can study/compare the various treatment cases :)
Sadly, I have not yet launched streams yet for study. I know, I'm a lame-O. I'll get to it shortly, prolly just spin up a local VM on Proxmox for that here, I really am anxious to give it a go :)
Our implementation is an endorsement of @trwnh's proposal that the context property be given additional formalization.
During the last ForumWG call, they intentionally (or perhaps unintentionally) summarized their desire that implementors should "just use collections", and that that would be a good starting point for future iteration.
With the current state of context being "there is no coordinated usage of context", this topic aims to provide a snapshot of implementors' use of that property (or lack thereof), and to stimulate further discussion on potential use cases.
Mastodon — does not use context, but provides an ostatus:conversation property
Pleroma/Akkoma — uses context, but the url provided is unresolvable, likely used similarly to Mastodon
Streams (@mikedev) — uses context, resolves to an OrderedCollection containing all activities encontered (Creates, Updates, etc.)
My hope is that a provided context resolving to a Collection (or subtype thereof) would allow for proactive topic backfill, instead of relying on reply chain traversal, which while workable, has some rather specific downsides.
As mentioned per the above linked announcement that NodeBB was following FEP-7888:
We attach context to all Note objects (NodeBB posts), and it resolves to an OrderedCollection that contains the uris to the other objects in the context (the NodeBB topic).
I have created a spreadsheet with open editing permissions (for now) and invite implementors to add their implementations if applicable.
One thing I am noticing now (and should've expected) is that not every software has the concept of a discrete context, nor can you expect one from remote activities. In those scenarios, the fallback seems to be to point to the root-node Object and iterate via replies collection.
For example:
@mariusor's FedBOX defines context as the root-node Object.
@mikedev's (streams) has a concept of conversation containers, and if context is received, inherits it, but otherwise, context becomes the root-node Object.
I'm confused about a particular aspect of Inbox Forwarding as detailed in the ActivityPub spec:
... the server needs to forward these to recipients that the origin was unable to deliver them to. To do this, the server MUST target and deliver to the values of to, cc, and/or audience...
... The server MUST only target the values of to, cc, and/or audienceon the original object being forwarded, and not pick up any new addressees whilst recursing through the linked objects (in case these addressees were purposefully amended by or via the client).
Emphasis mine.
My reading suggests that only the values of to, cc, and audience on the referenced object should be used, and not those values on the activity itself.
But doing so would preclude the use of Inbox Forwarding in scenarios where the Activity wrapper contains additional addressees that the underlying object does not have.
e.g. A Note by A contains a single addressee: as:Public. It is then Announced by B and C. Later, A updates the Note, and their server sends out Update(Note) with the following addressees: as:Public, B, B/followers, C, C/followers, but the object referenced still contains a single addressee: as:Public.
In that case, when received by B and C, should they forward the activity to their followers?
For a lot of things in ActivityPub, there are almost direct parallels in NodeBB. An as:Note object pairs well with a NodeBB post, an as:Person is a NodeBB user, etc.
One thing that didn't map 1:1 was the Delete activity, which at surface level, seems rather straightforward — just delete the object! However, once you dig in, there are some additional considerations:
in NodeBB, we have two separate states for content removal.
A delete, where the post is still present (but its content unavailable to non-privileged users), and a
A purge, where the post is scrubbed from the database entirely, and all references to it, removed
in ActivityPub, there is a single activity, as:Delete
Implementors may opt to replace the object representation with an as:Tombstone (how quaint!), but they may also just opt to use a 404
So there are some nuances that are left intentionally vague.
This is how NodeBB will interpret the protocol specification, and how we will align it with our own dual-state post deletion mechanic (delete & purge):
When a local post is deleted, we will federate out an Update(Tombstone) referencing the id
Afterwards, if the content is retrieved, an as:Tombstone will be served.
Deleted posts in NodeBB still maintain their place in the topic, so when the context is retrieved, the note will still be present in the collection.
If we receive an Update(Tombstone), we will delete the local representation of the post
When a local post is purged, we will federate out a Delete(Note)
Afterwards, if the content is retrieved, we will serve a 404
The note will no longer exist in the context collection
If we receive a Delete(Note) (or Article, or Question, etc.) we will not delete it immediately. Instead, as kaniini advises, we will attempt to retrieve the object from the origin:
If we see an as:Tombstone, we will delete the post (soft delete)
If we encounter a 404 or 410, we will purge the post (hard delete)
I'm writing this out less as a guideline for myself, but to solicit opinions and to give others a chance to point out if I've interpreted the spec incorrectly.
Just my thought, but the whole Delete then Purge has always irritated me.
Delete should just be Delete.
If a Mod wants to temporarily hide something they could move post, or delete and keep a copy.
The only thing Delete then Purge does is add extra step to removing something!
Finally, you are now able to look up remote content and user profiles using the built-in NodeBB search tooling.
In the quick search bar and on the search page itself, you can paste in a URL to a post. If NodeBB can fetch it using the ActivityPub protocol, then it will be immediately parsed and returned as a search result:
This change resolves the final hurdle stopping a brand new NodeBB from connecting to the fediverse. It wasn't possible to actually find anyone or anything in order to start those first follow relationships. Now it is possible.
Aside — I'm frankly surprised by how long it's taken for me to actually do this. It goes to show you just how much you'll put off doing something if it's not really critical.
This is merely exposing the frontend UI to the already established backend logic.
We have two methods internally that are used for this:
Notes.assert, which when given a object url or id, parses it and attempts to resolve the parent chain all the way to the top-level post. It then creates a topic to house all of those posts.
Actors.assert, which when given an object url, id, or handle, creates a local representation of the user.
How come "query"/etc. didn't show up?
For both user and post searching, if the passed-in url does not resolve or does not resolve to a processable object, then we do not proceed. It's important to realize that while in an ideal world, we'd all be passing immutable identifiers everywhere, the real world is just a bit messier.
Search queries could be a post or user URL, or a webfinger handle, so additional logic was required to handle those use cases. Most ActivityPub-enabled software I've encountered handle these vanity URLs when queried via ActivityPub — it returns the appropriate representation for processing. Some do not, and so in those cases, those items will not show up in the search results.
You know what I just noticed about @mike's DotSocial podcast? The introductions are always succinct and to-the-point. There's no 30-second "John Smith spent 15 years at X doing Y with Z, and revolutionized foo by barbaz, and is also on the board of Fizzbuzz. He is a leading champion for..." blah-de-blah-blah.
Take @snarfed.org@snarfed.org's introduction:
The beauty of an open system is that anyone can build on top of it, and try to make it a better place, in the fediverse, software engineer Ryan Barrett is one such developer. Most recently, Ryan built a bridge to connect Bluesky, which uses the AT Protocol, to Mastodon and other platforms, using the ActivityPub protocol. He wanted to advance the fediverse's promise of interoperability. His work ignited a firestorm, revealing learnings, lessons, and insights discussed today.
I never realized how often meaningless polished intros happens on podcasts, radio shows, TV interviews, etc., because I've just learned to tune it all out.
... or maybe it's because if you're an ActivityPub dev, Ryan needs no introduction 😆
As of today, the NodeBB-ActivityPub implementation now supplies both context and audience properties with every post.
N.B. When I say context and audience, these are also terms used by the ForumWG that refer to "topic" and "category", in NodeBB parlance.
Early indications from the last ForumWG meeting indicate movement towards the inclusion of context in a low-level as:Note object (a federated NodeBB post), resolvable as an as:Collection or as:OrderedCollection. The latter is what NodeBB will send, ordered by post time.
Discussions with @angus also suggest that Discourse has the ability to parse an as:OrderedCollectioncontext if provided, but currently does not if encountered as a property in a Note.
A minor change today also updates the audience property, which used to erroneously point to the context/topic, but now points to the audience/category. This change aligns usage of this property with FEP-1b12's expectations.
This change should allow other implementors to:
automatically group objects together given a the provided context, and
more thoroughly backfill a given object's context, without relying on inReplyTo traversal
Dmitri invited participants to the regular SWICG call tomorrow; best place to be informed of upcoming events: SocialCG calendar — "please come by, it is free for everyone to join or listen in"
Angus provided an update to the working group's inclusion under the banner of the Social Web Incubator Community Group (SWICG), revised name would be the Forums and Threaded Discussions Task Force, or "ForumWG" for short.
Julian provided an update on this past month's usage of the fediverse to hold asynchronous discussion, a number of threads have been started on the respective forum categories (both of which federate out) for the working group pertaining to discussions re: agenda items, and have been fairly well received.
Angus and Julian will update the respective handles of their categories to reflect the new working group name
"Lay of the Land" survey reports
Angus: The general spirit of these surveys is 'these are the existing X approaches, the plurality may indicate the need to converge'
Evan re-iterates that it is unlikely any implementors will change their nomenclature to match
Angus asks whether participants find utility in the list
Evan indicates that whatever is decided upon is best used "on-the-wire", Julian agrees and notes that the agreed-upon terminology would be used in the "Definitions" portion of any report written by ForumWG; suggests the list may be best kept as a living reference
Rimu indicates that as the list grows, alternative ways to represent the data may be required
Round of applause for Rimu for taking the initiative to start (and now maintain) the list
Impetus for topic: WordPress sending out as:Note when as:Article would be more suitable
@jupiter_rowland (in topic, paraphrased): Mastodon values microblogging UX and locked down their allowed html to satisfy this constraint, despite Hubzilla's pleas
@mikedev (in topic, paraphrased): Raised issue in 2017 to address issues with inline images being removed. Suggested a compromise: treat Article and Note differently (Note, text only with attachments; Article, full HTML) — Eugen 7 months later closed issue with change to further hamper treatment of Article, by showing only title and link back to source.
@pfefferle (in topic): "You can choose 'Note' if you want to have the best compatibility"
Evan: Whether a note or article is federated, it shouldn't hamper implementation; but as:Page should not be used
Mattias: Choice is given to user as to how WP maps the native Post object to ActivityPub. Historically sent out Article but received a lot of pushback from early adopters. Difficult to reconcile UX with technical limitations
Evan: "An as:Note is a Tweet (we just couldn't call it that), an as:Article is a blog post"
Emelia: "Should software publish different objects based on content length, even if using the same mechanism?"
a: Big picture view — it doesn't seem complicated, but it is, because the line between them is completely arbitrary.
Mattias: We try to autodetect (no headers, content length, etc.), would prefer different content types based on what users write, but the advantage is being able to read content natively on the user's platform of choice
Dmitri: "I think we've got several questions in parallel:
What SHOULD these things (Note & Article) be used for.
What to do about Mastodon who only seems to consume Notes."
a: The reason we're talking about this is because of various differring implementations - for example, in one implementor's mental model, you have a thread with a title and that is separate from the posts contained within; posts that may also have titles of their own. How do we reconcile this?
Julian and Rimu note that @renchap replied in-topic: "... we would like to improve how non-Note objects are processed/displayed in Mastodon."
Julian mentions a compromise put forth by @mikedev where Notes are smaller pieces of content with limited markup and attachments, and Articles are (sometimes) larger pieces with formatting, inline images. Additional survey/spreadsheet to be created, but we could as a group (Mastodon included) converge on a path forward and a report to the SocialCG could be authored. To be continued next month.
1b12 - announcing the activities of their actors, this is what Discourse and NodeBB do, other implementations have taken this approach
@nutomic (paraphrased): "intent of 1b12 is to describe the existing status quo"
400e - Pubicly appendable collections; Picked up by a few other folks, also potentially Mastodon (with their new groups implementation)
How do we treat group actors in forum/threaded implementations?
a: 400e - Groups send Add activities, 1b12 - Groups send Announce activities, otherwise, a Group could even send regular Creates (editor's note: this is a dramatic simplication of the actual post here)
Evan: announce style makes the most sense, understanding that folks use both - suggestion: document both but let consumers know they'll see one or both
Rimu: Implementors can make opinionated decisions on how it should work, and adjust based on the reality of how the major players adopt
Angus will continue collating responses into a spreadsheet re: group implementations
Can a group be multiple different things? e.g. a context/thread has some recipients, a context could be an actor. How forums choose to (or could) represent these relationships via ActivityPub is what is currently being solicited
a: Boils down to "Collections, please use them", but best to start foundationally: Notes in Collections, first.
Due to lack of time discussion of this will take place asynchronously on the fediverse: https://community.nodebb.org/post/99491 (if this does not open in your client, paste it into the search box)
Julian provided one user story: "If you want to share a context to others, one should share the higher-ordered collection, and not what we do today, which is to share the url/object uri for OP."
A suitable implementation could see that and backfill the entire context locally, and redirect the user to the first object.
Angus noted that Discourse already has some support for Collections, will provide details async on forum topic (linked above)
Action Items
@angus and @julian will update the respective handles of their categories to reflect the new working group name
@julian to collate responses to Article vs. Name among implementors, supply recommendation at next meeting.
@angus to collate responses re: Group federation among implementors, continue discussion next meeting
Unfortunately during today's ForumWG call, we did not have enough time to fully discuss @trwnh's desire to solicit feedback regarding the Fediverse UX for forums.
The next best thing is to collect those user stories via the fediverse and discuss again at the next meeting, so here we are!
@trwnh will start off the discussion with a reply here.
An update from last night brings some additional logic to the title generation of topics from the fediverse.
Previously if a title was provided in the name property, that was used as the topic title.
While that hasn't changed (and is the strongest signal for a topic title), not all fediverse content contains titles. Specifically, Mastodon posts do not require or even have a space to put a title in.
For those cases, we fall back to generating one based on the content. We literally grabbed the first 128 characters or so, and added an ellipsis to the end.
While that worked okay as a stopgap, it meant that a lot of topics ended up with really long titles — not ideal.
The new logic tries to grab the first line of text (either the first <p> or line), and from there, the first sentence, using some naive regular expressions.
While still not a proper alternative to... you know... specifying a title, it's better than nothing I suppose!
I wonder if other fediverse softwares implement title generation logic like this...