10
45
Fork
You've already forked doipjs
28

Improve ActivityPub support #56

Merged
yarmo merged 2 commits from improve-activitypub-support into dev 2023年09月18日 10:18:30 +02:00
Owner
Copy link

This PR fixes two issues when verifying ActivityPub profiles: using posts as proofs and nodeinfo support

Posts as proof

It was already possible to use posts as proof for Keyoxide, but the code never fully made a distinction between post data and profile data. The issue is that post data usually doesn't contain (much) profile data, so it's not feasible to obtain important things like preferredUsername from post data.

With this PR, the code checks if the user used a post as proof and if so, makes an additional HTTP request to get the profile data.

NodeInfo support

Quite a while ago, all ActivityPub-compatible projects were unified into a single "service provider" to solve a lot of issues:

  • if API is the same, how would doipjs know if a server is Peertube, Mastodon, Friendica...?
  • all AP-compatible services use identical configs inside the library
  • a new AP service appears? doip-js needs to be updated to support it

With a unified service provider, we diminish the config complexity and automatically support all future AP services.

However, doip-js was still unable to distinguish the different AP software.

With this PR, additional HTTP requests are made to determine whether the instance being queried supports nodeinfo and if it does, get the necessary data to make the distinction.

As demonstrated in the example data below, doip-js now reflects that a Mastodon server is mastodon, a Friendica server is friendica, etc.

Servers without nodeinfo support will still be called activitypub servers.

Example data

Claim {
 _uri: 'https://fosstodon.org/@yarmo',
 _fingerprint: '9f0048ac0b23301e1f77e994909f6bd6f80f485d',
 _status: 200,
 _matches: [
 ServiceProvider {
 about: {
 id: 'mastodon',
 name: 'mastodon',
 homepage: 'https://activitypub.rocks'
 },
 profile: {
 display: '@yarmo@fosstodon.org',
 uri: 'https://fosstodon.org/@yarmo',
 qr: null
 },
 claim: {
 uriRegularExpression: '/^https:\\/\\/(.*)\\/?/',
 uriIsAmbiguous: true
 },
 proof: {
 request: {
 uri: 'https://fosstodon.org/@yarmo',
 fetcher: 'activitypub',
 accessRestriction: 'none',
 data: { url: 'https://fosstodon.org/@yarmo' }
 },
 response: { format: 'json' },
 target: [
 {
 format: 'uri',
 encoding: 'plain',
 relation: 'contains',
 path: [ 'summary', [length]: 1 ]
 },
 {
 format: 'uri',
 encoding: 'plain',
 relation: 'contains',
 path: [ 'attachment', 'value', [length]: 2 ]
 },
 {
 format: 'uri',
 encoding: 'plain',
 relation: 'contains',
 path: [ 'content', [length]: 1 ]
 },
 [length]: 3
 ]
 }
 },
 [length]: 1
 ],
}
This PR fixes two issues when verifying ActivityPub profiles: using posts as proofs and nodeinfo support ## Posts as proof It was already possible to use posts as proof for Keyoxide, but the code never fully made a distinction between post data and profile data. The issue is that post data usually doesn't contain (much) profile data, so it's not feasible to obtain important things like `preferredUsername` from post data. With this PR, the code checks if the user used a post as proof and if so, makes an additional HTTP request to get the profile data. ## NodeInfo support Quite a while ago, all ActivityPub-compatible projects were unified into a single "service provider" to solve a lot of issues: - if API is the same, how would doipjs know if a server is Peertube, Mastodon, Friendica...? - all AP-compatible services use identical configs inside the library - a new AP service appears? doip-js needs to be updated to support it With a unified service provider, we diminish the config complexity and automatically support all future AP services. However, doip-js was still unable to distinguish the different AP software. With this PR, additional HTTP requests are made to determine whether the instance being queried supports nodeinfo and if it does, get the necessary data to make the distinction. As demonstrated in the example data below, doip-js now reflects that a Mastodon server is `mastodon`, a Friendica server is `friendica`, etc. Servers without nodeinfo support will still be called `activitypub` servers. ## Example data ```js Claim { _uri: 'https://fosstodon.org/@yarmo', _fingerprint: '9f0048ac0b23301e1f77e994909f6bd6f80f485d', _status: 200, _matches: [ ServiceProvider { about: { id: 'mastodon', name: 'mastodon', homepage: 'https://activitypub.rocks' }, profile: { display: '@yarmo@fosstodon.org', uri: 'https://fosstodon.org/@yarmo', qr: null }, claim: { uriRegularExpression: '/^https:\\/\\/(.*)\\/?/', uriIsAmbiguous: true }, proof: { request: { uri: 'https://fosstodon.org/@yarmo', fetcher: 'activitypub', accessRestriction: 'none', data: { url: 'https://fosstodon.org/@yarmo' } }, response: { format: 'json' }, target: [ { format: 'uri', encoding: 'plain', relation: 'contains', path: [ 'summary', [length]: 1 ] }, { format: 'uri', encoding: 'plain', relation: 'contains', path: [ 'attachment', 'value', [length]: 2 ] }, { format: 'uri', encoding: 'plain', relation: 'contains', path: [ 'content', [length]: 1 ] }, [length]: 3 ] } }, [length]: 1 ], } ```
Sign in to join this conversation.
No reviewers
Labels
Clear labels
bug
Something is not working

Archived

enhancement
New feature

Archived

Contribution welcome
Get started contributing here
Good first issue
Good if you are new to the project or to open source contributions
Impact
External
Affects the people using the project
Impact
Internal
Affects on the people working on the project
Priority
Critical
Work on right now
Priority
High
Work on at earliest convenience
Priority
Low
Work on in spare time
Priority
Medium
Work on regularly
Review
Duplicate
Already exists
Review
Off Topic
Does not fall within the scope of the repo/project
Status
Backlog
Is not being worked on yet
Status
Blocked
Is waiting on something or someone
Status
Completed
Is done
Status
In Progress
Is being worked on
Status
Investigating
Is waiting on research or questions
Status
Needs Decision
Is waiting on a decision by the devs/contributors
Status
Needs Info
Is waiting on additional information before it can be solved
Status
Needs Triage
Is new issue that needs reviewing
Status
Testing
Is being checked and verified
Status
Waiting For Review
Is waiting on reviewers to approve
Status
Won't Fix
Won't be fixed
Type
Bug
Related to something not working as intended
Type
CI
Related to continuous integration
Type
Documentation
Related to documentation
Type
Enhancement
Related to a new feature or an improved one
Type
New Claim
Related to a new identity claim/proof
Type
Security
Related to security
Type
Tests
Related to code tests
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
keyoxide/doipjs!56
Reference in a new issue
keyoxide/doipjs
No description provided.
Delete branch "improve-activitypub-support"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?