@[email protected] I am building ActivityPub integration into the next major version of NodeBB. It is still in development but moving towards an alpha release soon
-
Sometimes on #mastodon I see an interesting question, and think "hey I'd be interested in the answers". -
I've been exploring the fediverse intermittently since last year. As a reflection of my journey so far, I wanted to put down some thoughts:@[email protected] what you're experiencing is a protocol that is largely still in development. The specification is largely solidified but implementations differ widely for numerous reasons.
I implore you not to write off the fediverse for those reasons, ActivityPub is still in a nascent, growing stage, and rough edges will be smoothed over in time.
To expect a panacea is naive at this time, but the optimism and potential are both there.
-
Reconciling ActivityPub Deletes with NodeBB deletion@eeeee said in Reconciling ActivityPub Deletes with NodeBB deletion:
The only thing Delete then Purge does is add extra step to removing something!
Technically they needn't be two steps. You could just go straight to purge.
We toyed with the idea of removing deletes altogether... not sure where we landed haha @baris?
-
Reconciling ActivityPub Deletes with NodeBB deletion@[email protected] — interesting idea, but my gut feeling is no, because post visibility (which at present, NodeBB doesn't even support at all) and deletion are two separate properties in ActivityPub.
One is defined in the object itself (
to
,cc
, etc.), whereas if a post is deleted, it simply ceases to exist or becomes a Tombstone. -
Addressing Hyperlink Formatting Issue with Double Comma (e.g., M.Kn) in NodeBB v1.18.5@clover try changing your hook function to edit
postData
in place and return it directly, rather than creating a new object. -
Replacing header/user image with something else@NodeHam Are you referring to the user "cover photo"?
-
Do you have limited or full access to your host?@NodeHam Right, so that's the thing that's different about this whole decentralized social network thing.
There's no magical engagement algorithm that allows your content to reach other people. If nobody follows you, it doesn't get sent out to other services, so the post stays local to this NodeBB forum.
To get follows, you have to follow others, and hopefully someone with many followers (like my crag.social account) will "boost" your post
You might've noticed that every time I post about ActivityPub, either my crag.social account, or the NodeBB account on fosstodon.org shares it (sometimes both). That's because those two accounts have much higher follower counts than my NodeBB account. That difference will lessen over time
-
Sometimes on #mastodon I see an interesting question, and think "hey I'd be interested in the answers".@[email protected] @[email protected] no, Mastodon doesn't have the concept of following a topic.
It's up to the software implementor to do something like that.
NodeBB, for example, does allow you to subscribe to a topic. My replying here automatically subscribed me to the topic so future responses (even if I'm not mentioned), will notify me.
-
Blog comments on external blog website@crazycells ah sorry, I didn't respond because I wasn't sure...
But I think it should be fine. Technically according to browser security policy, nodebb.org and community.nodebb.org are essentially different sites.
So if you used a different domain the same restrictions apply, but the plugin should still work.
-
Do you have limited or full access to your host?@NodeHam were you looking for opinions from outside of this forum? Let me share your post and see what happens
-
Reconciling ActivityPub Deletes with NodeBB deletionFor a lot of things in ActivityPub, there are almost direct parallels in NodeBB. An
as:Note
object pairs well with a NodeBB post, anas: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.
Kaniini on SocialHub makes the argument that a Delete should be treated like a cache invalidation, which has its own merits.
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)
- If we see an
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.
- in NodeBB, we have two separate states for content removal.
-
Could someone please come over, put a gun to my head and force me to pick a fucking laptop@[email protected] I am new yes hehe.
Is it related to s2_idle vs deep? I'll admit I haven't had any major issues with the battery draining unexpectedly fast when suspended.
-
A forum for New_ Public?@[email protected] I'm curious to see whether your team evaluated forums as a viable means to communicate and comment re: news stories.
The forums of yesteryear are done and dusted, a future of federated forum softwares await...
-
Could someone please come over, put a gun to my head and force me to pick a fucking laptop@[email protected] just get a @[email protected] laptop and never look back.
Bonus points, you get to play Ship of Theseus with it too!
-
Two NodeBB instances on same serverThere's are other reasons to have two separate NodeBB installs:
- you may want to run different sets of plugins
- uploaded files are stored within the NodeBB directory, best to keep those separate
- plugins like emoji and customize store files specific to a certain forum, and all plugin files are within the NodeBB folder
-
Sorry Go to Social folks.@[email protected] hahah man, what happened? Now I want to see this post so I can also use the tag "wrong"
-
Why does /recent only display one topic for all users@phenomlab that doesn't sound like out of the box behaviour... can you reset all plugins and see if it reproduces?
-
Pre-Alpha ActivityPub-related bug reports@the-skyfoxx that's intentional, it acts more like a category than a list of unread topics.
So you can mark a topic as read but it'll stay there, just like marking a topic read in an existing category.
-
Remote post and user fetching via search toolingTechnical stuff ahead ...
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.
-
Remote post and user fetching via search toolingFinally, 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:
If you change the search type to "In users", or use the search bar in the users page, then you can look up remote users using their URL or handle:
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.