Spyke

Posts

technical-discussion·Technical Discussionbyjulian

@misskey-dev/node-http-message-signatures now v1

It seems that this past week @[email protected] released @misskey-dev/node-http-message-signatures, which contains some breaking changes.

At this time I am unsure what the difference is between joinmisskey/node-http-message-signatures and misskey-dev/node-http-message-signatures.

The latter is still dormant, but the former has received quite a bit of work as of this past week.

NodeBB has its RFC 9421 implementation built using v0.0.11 of this package.

View original on activitypub.space
2
technical-discussion·Technical Discussionbyjulian

FEP-c0d0: Context Locking

This is the main discussion thread for the draft FEP-c0d0: Context Locking

Summary

Context locking (and its inverse, unlocking) refer to the action whereby a topic no longer accepts new replies.

This proposal introduces a locked property on the context object, and a new activity type, Lock, to signal changes to a topic's locked state across the fediverse. Unlocking is expressed with the standard ActivityStreams Undo activity, applied to the original Lock. It builds on FEP 1b12: Group federation for audience identification (the audience property) and the Announce wrapping pattern, and on FEP fe34: Origin-based security model for authorization.

This FEP is a sibling of FEP f15d: Context Relocation and Removal, which covers the Move and Remove moderation actions.


The full FEP text can be found at https://w3id.org/fep/c0d0

View original on activitypub.space
technical-discussion·Technical Discussionbyjulian

Dismissing HTTP Signature on presence of Object Integrity Proof

I have a question for implementors pursuing object integrity proofs.

I am implementing the ability to serve these proofs in NodeBB with the assistance of an LLM. It is adhering to @[email protected]'s FEP-8b32: Object Integrity Proofs.

As part of its work, it implemented a quirk I thought was curious. If the proof was present in an embedded object, the activity's HTTP signature was ignored/not-checked.

I challenged the model and it pointed to this line from the FEP...

> If both HTTP signature and integrity proof are used, the integrity proof MUST be given precedence over HTTP signature. The HTTP signature MAY be dismissed.

... and cited potential interop if someone were to send an activity with integrity proof but explicitly no HTTP signature. That is, if NodeBB were to implement a hard requirement for HTTP signatures, then that specific case would fail inbound checks.

My rationale is:

  • The HTTP signature guarantees that the payload has not been modified in-transit, and
  • The proof guarantees the authenticity of the payload, and
  • This is doubly so for payloads belonging to separate origins

Am I incorrect? It would seem like we need to exercise both checks to ensure authenticity of the entire payload chain: activity and object.

Pinging other interested parties: @[email protected] @[email protected] @[email protected] @[email protected]

View original on activitypub.space
1
technical-discussion·Technical Discussionbyjulian

Detecting duplicate activities

How does one go about detecting duplicate activities, and what is the best practice for senders?

I ask because following a hashtag served by relay.fedi.buzz responds with an Accept with id https://relay.fedi.buzz/activity/accept/%7Bactor%7D/%7BrequesterInbox%7D

Because that URL does not have a random/time-based component, an unfollow followed by a refollow will lead to an Accept with the exact same id.

In NodeBB's case, it detects this as "already seen" and silently drops it.

I could ask @[email protected] to add a timestamp in the ID, but I was wondering if my duplicate detection strategy was naive :smile:

View original on activitypub.space
1
technical-discussion·Technical Discussionbyjulian

FediBuzz webfinger backreference failure

Hi @[email protected], I think I found a bug with FediBuzz and how it does its Webfinger responses.

In a nutshell, FediBuzz tag actors have preferredUsername set to tag-whatever, but the corresponding webfinger lookup ?resource=acct:[email protected] fails with a 404, but [email protected] works fine.

cc @[email protected]

AI slop explanation follows (feel free to ignore!):

> tags.pub does it correctly: > > json > { > "id": "https://tags.pub/user/nodebb", > "preferredUsername": "nodebb" > } > > > WebFinger acct:[email protected] → resolves to https://tags.pub/user/nodebb ✅ > > FediBuzz breaks the round-trip: > > json > { > "id": "https://relay.fedi.buzz/tag/nodebb", > "preferredUsername": "tag-nodebb" > } > > > WebFinger acct:[email protected] → 404 ❌ > > Yes, it's a FediBuzz bug. preferredUsername must match the WebFinger subject so that acct:{preferredUsername}@{hostname} resolves back to the actor's id. FediBuzz added a tag- prefix to preferredUsername but didn't update WebFinger to match. > > They should either use preferredUsername: "nodebb" (matching tags.pub) or serve WebFinger for acct:[email protected].

View original on activitypub.space
1
technical-discussion·Technical Discussionbyjulian

EmojiReact vs. Like w/ content?

Hm... FEP-c0e0: Emoji reactions details two ways to federate an Emoji reaction:

  1. EmojiReact activity
  2. Like with content (as opposed to a regular Like, which has no content)

In testing, I noticed that misskey (or at least, the site I was testing with, birb.space) sends the latter. I don't know what sends the former, and if NodeBB were to start federating out EmojiReact, would it be broadly understood?

Perhaps I should federate out both at once.

cc @[email protected]

View original on activitypub.space
technical-discussion·Technical Discussionbyjulian

Edge case when backfilling topics

When it comes to backfilling topics, NodeBB utilises what is called "context collection backfill" instead of reply-chain traversal. In a nutshell, instead of crawling up and down the reply tree one-by-one — kind of like what Mastodon does currently — it checks for a canonical source-of-truth in the context property.

NodeBB supports both strategies, since not all objects contain context.

I found a fun little edge case where if I start a topic, a reply is received, and that reply points to my instance, it won't catch any replies made in between.

In other words:

localA starts topic → remoteB replies → remoteC replies to B only → remoteB replies to C and A

In this scenario, because my instance A is left out of the third activity, I don't know about it. When the fourth activity appears, the context is checked, C's reply isn't in it, and I proceed without knowing about it. Oops!

In this case, when incoming replies reference a context that is same-origin to your own instance, you should not use context collection backfill, because:

  1. You already have the entire context, so it's unnecessarily duplication of work
  2. You won't catch any replies made out-of-band unless you do reply-tree traversal

Tagging @[email protected] because this is related to FEP f228.

View original on activitypub.space
2
technical-discussion·Technical Discussionbyjulian

Can WebFinger resolve subject to a different domain?

Can WebFinger resolve subject to a different domain?

My immediate assumption is yes, it can, because someone may use a specific domain merely as a gateway, and point to a different domain for resolution.

e.g. https://activitypub.directory/.well-known/webfinger?resource=acct%3Ajulian%40activitypub.space (note the different TLD)

Resolving to:

{"subject":"acct:[email protected]","aliases":["https://activitypub.space/uid/1","https://activitypub.space/user/julian"],"links": ...

However, this is a potential security issue because said directory could then poison the resulting data, especially if cached by a user of that webfinger directory.

Am I wrong about that? In the meantime I've updated NodeBB's code to strictly enforce webfinger lookups so if a response subject has a different hostname, then the webfinger query result is considered invalid.

View original on activitypub.space
technical-discussion·Technical Discussionbyjulian

FEP-baf5: Administrator Collection

This is the discussion thread for the draft FEP-baf5: Administrator Collection

> This FEP introduces a mechanism for discovering the administrators of an ActivityPub instance. It extends the "Group Moderator" pattern from [FEP 1b12][1b12] and the "Application Actor" concept from [FEP 2677][2677] by defining an OrderedCollection of administrators referenced from the instance's application actor.

The full draft can be read here.

View original on activitypub.space
technical-discussion·Technical Discussionbyjulian

Question re: Origin Based Security Model (FEP-fe34)

I received a security vulnerability report regarding NodeBB's handling of Update and Delete activities.

tl;dr

  • NodeBB implementes FEP fe34, and treats Update and Delete activities as valid if the activity's actor and the object's attributedTo differ but the origins are identical.
  • e.g. @[email protected] is allowed to federate Delete(Note) on @[email protected]'s Note.
  • The origin-based security model allows for moderator-style actions (third-party post editing and deletions) in the absence of explicit moderator claims.
  • The reporter disagrees that this should be allowed.

Are they right?

I responded that FEP fe34 allows for this behaviour because we do not have ready access to an instance's admin or moderator list. By conducting same-origin checks and allowing Update and Delete through for same-origin (but different identifier), we allow for moderators to federate their actions across instances.

Their response:

> I respectfully disagree that FEP-fe34 permits this behavior. Below are direct quotes from the specification that contradict your assessment. > > 1. ActivityPub spec (quoted in FEP-fe34 Rationale, Section 7.3 Update Activity): > > ▎ "The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin." > > Note: "at minimum" means same-origin is the floor, not the ceiling. Authorization must still be verified. >2. FEP-fe34 — Authorization > Ownership: > > ▎ "The actor that creates an object MUST be its owner." > ▎ "The owner of an object is permitted to modify and delete it." > ▎ "Update and Delete activities, and objects indicated by their object property are expected to have the same owner." > > "Same owner" means the same specific actor — not any actor on the same domain.

I responded back with the following:

> "The actor that creates an object MUST be its owner." > >
> Correct, the creator must be an owner, no impersonation allowed. >
> > "The owner of an object is permitted to modify and delete it." > >
> A strict reading of this does not preclude the ability of a same-origin moderator to modify and delete the object. This is my argument. >
> > "Update and Delete activities, and objects indicated by their object property are expected to have the same owner." > >
> Again, "expected to" does not rise to the level of MUST. >
> I agree out of principle that the security implications exist, but if you follow through with the exploit, it requires a non-compliant server to allow users to publish Update and Delete for other users on the same instance, and even then the exposure is limited to users of that origin only (e.g. your server cannot arbitrarily delete my posts). This is the foundation of the Origin-based security model.

So we are at an impasse as to whether my strict reading of the FEP is adherent to the spirit of the FEP itself. Here's where you come in... do you agree with me, or the reporter?

Directly tagging @[email protected] (as FEP author), @[email protected] and @[email protected] (both subject matter experts) for their thoughts.

View original on activitypub.space
technical-discussion·Technical Discussionbyjulian

Multiple handles for Activity Intents

Hi @[email protected] I've got a question about Activity Intents!

I'm implementing it now (as you noticed) and have run into an interesting issue. The wording of 3b86 suggests that the intents are distinct between users. That is, the end user inputs their handle, the handle is queried via webfinger, and supported Intents are returned.

However, the intents themselves don't really distinguish between users.

So I could have a localStorage session with multiple handles registered (e.g. [email protected], [email protected]), etc. — this works fine.

But if I had two handles with the same domain, [email protected] and [email protected], then my intents can't be targeted, can they... I just fire off the request (or rather, I have the end user's browser navigate) to the intent URL and whatever account is logged in will be the actor.

Did I miss something, or was there a way to distinguish actors in Activity Intents?

P.S. I find it highly amusing that you had to click through to activitypub.space to read my whole post, but because I don't support Activity Intents yet, you can't reply properly :rolling_on_the_floor_laughing:

View original on activitypub.space
-1
technical-discussion·Technical Discussionbyjulian

Re: @peertube/http-signature

@[email protected] I have a question for you... I'm seeing in Are we HS2019 yet? that Peertube and Misskey both use your package: @peertube/http-signature

NodeBB currently rolls its own cavage-12 support but and I did some preliminary research into updating to the latest HTTP Signatures draft, but quickly got overwhelmed.

For a variety of reasons, but mainly to avoid NIH, I'd consider switching to a dependency.

My question is: does your library support verification for non-hs2019 signatures, or will I need to invoke your library in front, and fall back to existing cavage-12 verification otherwise?

I suppose, same question re: double-knocking.

View original on activitypub.space
0
technical-discussion·Technical Discussionbyjulian

Catodon federating deletes of objects it doesn't own

Hey @[email protected], now that I'm tracking errors encountered, I've got a bit more visibility into things that normally would've just been caught and ignored.

Today I received a Delete(Object) from Catodon associated with a user from catodon.rocks.

Two things:

  1. Its object referenced an item outside of catodon.rocks, and so it failed NodeBB's actor-object match check. Normally people can't delete other peoples' posts, so I think this might be a mistake?

  2. The activity's audience matches the activity's attributedTo. While you're certainly allowed to put anything you want in there, threadiverse software uses it to point to a group actor. Wondering if this was intentional.

Thanks!

View original on activitypub.space
0
technical-discussion·Technical Discussionbyjulian

Native discovery of related tags (fedibuzz/tags.pub)

I was talking to my marketing guy about integrating a tags-based onboarding workflow for freshly installed forums.

The gist of it is, the forum admin adds a couple tags for the forum to globally follow, and achieves this via fedibuzz relay or tags.pub. Auto-categorization rules are automatically added and the forum starts receiving new (highly relevant!) posts through the magic of hashtag+federation ✨

He then asked whether it was possible to suggest related tags (e.g. add guitar suggest acousticguitar, electricguitar, etc.) for the admin to also add, to which I replied in the negative "for now".

But that got me thinking, is this something fedibuzz or tags.pub could achieve/offer in its API? It would require a bit of data analysis, to match up common hashtag usage, but doable maybe?

cc @evan [@evan@cosocial.ca](https://activitypub.space/user/evan%40cosocial.ca) @[email protected]

View original on activitypub.space
3