Darkscribes Community

@jasonwch latest NodeBB should have this patched already, thanks.

@jasonwch no, I javent looked into the issue yet 🫤

> julian said:
>
> the Activity Intents behaviour is meant to be active even if federation is disabled.

Actually, you're right, it's not meant to work without federation

@jasonwch the Activity Intents behaviour is meant to be active even if federation is disabled.

I'll fix up the behaviour so it is consistent even if federation is disabled.

@DigiDev not entirely sure. It's the expectation here that we download the photo and cache it locally?

@informapirata I am not certain whether Mobilizon publishes FEPs for how they use the Event activity. That would help, otherwise I would be reverse engineering their implementation, and that is not the easiest approach.

Hello again @informapirata!

It depends what kind of activity they send over. Most likely we just haven't cleared it for processing by NodeBB.

Any object type that we don't recognize we ignore for now, but there's no reason we can't look into it and clear it

Well, the whole idea behind them being resolvable is so that when they are acted upon (by the context owner), they can be queried.

For example if I receive a Delete(Context), I'll resolve it to find the root level post, and from there find my local representation, and delete it, assuming the actor was allowed to delete it.

They're only server generated views per current usage... but why do they have to be constrained to that usage?

I think Announce(Delete(Object)) skirts around that, though. Maybe not if you're being technical about it, but the shape of the activity is different enough to mean something else in 1b12-land:

• A community/group-actor announced a Delete
• The object may or may not belong to the same domain as the community/group-actor or Delete actor
• Verify that the community/group-actor and Delete actor are same-origin (might not need this if cross-instance moderation is a thing)
• Verify that the Delete actor is a moderator of the community/group-actor as per 1b12

@[email protected] got it, thanks. How do you reconcile the Delete coming from outside your domain? I would figure Mastodon would drop those Deletes.

Edit: that was confusing wording... I mean — how do you sign a Delete for an object that doesn't belong to your instance?

@[email protected] Do you send the Undo(Announce(Create)) as well for microblog compatibility?

Could it be you need to reindex the search? Sometimes things can get missed.

@[email protected] Yes you're right, some messiness is bound to happen.

I'm not trying to force all implementations into a specific inheritance pattern, that's why it's a "should", not a "must".

Even then one of my concerns is that while in an ideal scenario, everybody inheriting their parent context leads to an entire collection all referencing the same context... in reality a lot of messiness will occur, objects will reference other contexts all over the place, etc.

At the end of the day it's best effort, and if we are able to handle all that and still get to a point where backfill is achievable, then that's a win in my books.

> it depends on how much you embrace the idea of each publisher being allowed to make their own claims (and how much you allow "clean up" after the fact)

Part of me would like this to not happen, but it is unavoidable.

Good question — in my opinion, 7888 serves as a gentle introduction into the entire concept of conversational contexts. It's meant to be descriptive in order to capture the variety of existing implementations of context that are found in the wild (e.g. Pleroma context which doesn't resolve, contexts that are not URLs, etc.)

Each subsequent FEP "down the tree" (or up, depending on how you look at it) narrows the scope and upgrades verbiage in order to enable additional functionality.

Specifically pertaining to 11dd:

• Ownership is explicitly defined and is now a requirement, 7888 mentioned attributedTo and context ownership as examples only.
  • This upgrade was done to set the stage for subsequent FEPs for forking, merging, moving, etc.
• Activities should be sent to the context owner. This is identical to 7888, but re-stated as a reminder.
• A specific recommendation for inheritance is included (adopt the immediate parent's context, more if able), while 7888 allows for one to drop context altogether, inherit, or create your own.

This is not to say that 7888 is deficient in any manner. On the contrary, it's working entirely as intended!

In practice, Lemmy has adopted 7888, but at this time will not adopt 11dd. @[email protected] creates a context local to the instance, for each post because each instance is expected to be the canonical representation of the context, even if they are cached representations of remote federated content.

It means it would preclude Lemmy from adopting further upgrades like forking/merging/moving/locking, but it doesn't mean they are wrong in doing so.

@[email protected]

> I don't quite understand what "its own context" means here.

This line was lifted from an earlier draft where additional examples of defining ones own context, removing a context, or inheriting a context, is spelled out explicitly.

I realized after drafting that that was already more or less described in 7888 and so brevity won out.

I will need to reword that.

@yasas turning on "I'm Under Attack" mode will likely block search engine crawlers as well.

It is meant to be used as a last resort.

I also think that backfill will have a side effect of connecting the threadiverse and the rest of the fediverse.

Exposing context collections will mean consumers will be able to see both *verses. Once Mastodon starts consuming them I predict you will start seeing much more engagement from the microblogs.

The same would apply if Piefed or Lemmy begin consuming them as well.

That is an angle I had not even considered until now!

This past June, I put together a write-up about two major approaches to backfilling conversations. The ability to properly backfill conversations means we will be able to make major inroads toward solving the feeling that the fediverse is quiet.

I, alongside several other members of the SWICG Forums and Threaded Discussions Task Force (ForumWG) have been working toward building implementor support for Conversational Contexts — the ability to explicitly classify a set of objects as belonging to a conversation, whether that be a topic, reply tree, or similar.

I am happy to report that we have made some wonderful inroads this past few months!

• @[email protected] has been working closely with the Mastodon team to allow software to backfill from Mastodon — this pull request has now been approved! <img class="not-responsive emoji" src="https://community.nodebb.org/assets/plugins/nodebb-plugin-emoji/emoji/android/2705.png?v=537c260246d" title="" />
• I have been working with both @[email protected] and @[email protected] to allow software to backfill from Lemmy and Piefed, respectively. (Lemmy PR, Piefed issue) <img class="not-responsive emoji" src="https://community.nodebb.org/assets/plugins/nodebb-plugin-emoji/emoji/android/2705.png?v=537c260246d" title="" />

This marks a major milestone in the adoption of conversational contexts. With Mastodon on board backfill will be possible with the majority of the microblogiverse. With Lemmy and Piefed on board, backfill will be possible with the majority of the threadiverse.

Remember that @[email protected] was an early adopter of conversational contexts, and we have been able to backfill from WordPress blogs for quite awhile now (so that's the blogiverse too) <img class="not-responsive emoji" src="https://community.nodebb.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f60a.png?v=537c260246d" title="" />

I for one, am eagerly awaiting the next version of all of these softwares!!

@D1re_W0lf those rules do not seem to help, I have enabled them as well.

@yasas we have been seeing the same behaviour starting perhaps a week ago. The bursts seem to happen for maybe half a day and then disappear.

Since we wanted the site to start working quickly, we opted for an allow-list approach. We turned on "I'm under attack" mode, which has some unfortunate side effects (namely, causing federation to stop).

These are our rules:

(any(http.request.headers["accept"][*] eq "application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\"")) or (any(http.request.headers["accept"][*] eq "application/activity+json")) or (http.request.method eq "POST" and starts_with(http.request.uri.path, "/inbox")) or (starts_with(http.request.uri.path, "/assets")) or (starts_with(http.request.uri.path, "/.well-known"))

This lets (respectively):

1. ActivityPub fetches
2. Same
3. ActivityPub publishes to the NodeBB inbox
4. Static assets
5. Certbot and webfinger (also for AP)

You're right! NodeBB serves an outbox but doesn't put anything in it.

Happy to work towards rectifying it... It just didn't seem to break anything and you're honestly one of the first who even noticed