10
45
Fork
You've already forked doipjs
28

WIP: Add support for cohost profile claims #32

Draft
voteblake wants to merge 1 commit from voteblake/doipjs:cohost into main
pull from: voteblake/doipjs:cohost
merge into: keyoxide:main
keyoxide:main
keyoxide:dev
keyoxide:fix-irc-fetcher
keyoxide:new-claim-eveonline-143
keyoxide:prepare-new-release
keyoxide:fix-jsdoc-types
keyoxide:yarn-to-npm
keyoxide:support-openpgp-aspe-claims
keyoxide:support-html-alias
keyoxide:improve-activitypub-support
keyoxide:v1-restructure
keyoxide:into-es-module
keyoxide:support-aspe
keyoxide:fix-js-lsp-issues
keyoxide:improve-linting
keyoxide:add-markers
keyoxide:support-opencollective-claim
keyoxide:support-entity-decoding
keyoxide:use-rome-tools
keyoxide:support-cloudflare-buster
keyoxide:support-fediverse-posts
keyoxide:matrix-room-verification
First-time contributor
Copy link

What?

This PR adds support for verification of profiles on cohost.

Why?

cohost is a small but growing social media site that allows users flexibility and creativity in their posting through post-specific HTML and CSS.

How?

This PR makes the following changes:

  • Adds a new claim definition for cohost, relying on the existing HTTP fetcher to retrieve cohost profile pages in text mode.

Testing

I've added standard unit tests to the claimDefinitions/cohost.js file and verified a claim manually on the node REPL. This is my first time working with this codebase so there could be more to do. I'm particularly curious to verify if E.ProofAccess.GENERIC is appropriate here but am unsure how to test the browser use case.

Type ".help" for more information.
> const doip = require('./src')
undefined
> let claim = new doip.Claim("https://cohost.org/postl", "63c5fc9cb2c55fca1d1e108b05e4d0f7038f196c")
undefined
> claim.match()
undefined
> claim
Claim {
 _uri: 'https://cohost.org/postl',
 _fingerprint: '63c5fc9cb2c55fca1d1e108b05e4d0f7038f196c',
 _status: 'matched',
 _matches: [
 {
 serviceprovider: [Object],
 match: [Object],
 profile: [Object],
 proof: [Object],
 claim: [Array]
 }
 ],
 _verification: {}
> await claim.verify()
(node:17280) ExperimentalWarning: The Fetch API is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
undefined
> claim
Claim {
 _uri: 'https://cohost.org/postl',
 _fingerprint: '63c5fc9cb2c55fca1d1e108b05e4d0f7038f196c',
 _status: 'verified',
 _matches: [
 {
 serviceprovider: [Object],
 match: [Object],
 profile: [Object],
 proof: [Object],
 claim: [Array]
 }
 result: true,
 completed: true,
 errors: [],
 proof: { fetcher: 'http', viaProxy: false }
 }
}
## What? This PR adds support for verification of profiles on [cohost](https://cohost.org/rc/welcome). ## Why? cohost is a small but growing social media site that allows users flexibility and creativity in their posting through post-specific HTML and CSS. ## How? This PR makes the following changes: * Adds a new claim definition for cohost, relying on the existing HTTP fetcher to retrieve cohost profile pages in text mode. ## Testing I've added standard unit tests to the `claimDefinitions/cohost.js` file and verified a claim manually on the `node` REPL. This is my first time working with this codebase so there could be more to do. I'm particularly curious to verify if `E.ProofAccess.GENERIC` is appropriate here but am unsure how to test the browser use case. ``` Type ".help" for more information. > const doip = require('./src') undefined > let claim = new doip.Claim("https://cohost.org/postl", "63c5fc9cb2c55fca1d1e108b05e4d0f7038f196c") undefined > claim.match() undefined > claim Claim { _uri: 'https://cohost.org/postl', _fingerprint: '63c5fc9cb2c55fca1d1e108b05e4d0f7038f196c', _status: 'matched', _matches: [ { serviceprovider: [Object], match: [Object], profile: [Object], proof: [Object], claim: [Array] } ], _verification: {} > await claim.verify() (node:17280) ExperimentalWarning: The Fetch API is an experimental feature. This feature could change at any time (Use `node --trace-warnings ...` to show where the warning was created) undefined > claim Claim { _uri: 'https://cohost.org/postl', _fingerprint: '63c5fc9cb2c55fca1d1e108b05e4d0f7038f196c', _status: 'verified', _matches: [ { serviceprovider: [Object], match: [Object], profile: [Object], proof: [Object], claim: [Array] } result: true, completed: true, errors: [], proof: { fetcher: 'http', viaProxy: false } } } ```
Add support for cohost.org profile claims
All checks were successful
continuous-integration/drone/pr Build is passing
00c3dbe676
Rely on the existing HTTP fetcher to retrieve cohost profile pages. Uses text format, JSON may be a future option as the cohost API develops
Owner
Copy link

Hey, thanks for the PR and sorry for my late response.

Cohort looks interesting, hope the project succeeds!

Looking at the PR, what I am assuming it is doing is fetch the cohort profile page as is (i.e. HTML) and look for the fingerprint in there?

If this is correct, this would be dangerous, especially for a social media site as the content of a profile page is variable! Assuming users can "boost/retweet", a user could do so with a stranger's message containing a proof — don't ask me why they would :) but it's possible so it's needs to be taken into account. From that moment on, I assume the boosted message containing the foreign proof is displayed on the profile page and from that moment, is considered a valid proof by Keyoxide.

Are there plans for cohort to implement a minimalistic API? Could be as simple as https://cohost.org/user -> https://cohost.org/user.json which contains the same data, but in JSON format.

Hey, thanks for the PR and sorry for my late response. Cohort looks interesting, hope the project succeeds! Looking at the PR, what I am assuming it is doing is fetch the cohort profile page as is (i.e. HTML) and look for the fingerprint in there? If this is correct, this would be dangerous, especially for a social media site as the content of a profile page is variable! Assuming users can "boost/retweet", a user could do so with a stranger's message containing a proof — don't ask me why they would :) but it's possible so it's needs to be taken into account. From that moment on, I assume the boosted message containing the foreign proof is displayed on the profile page and from that moment, is considered a valid proof by Keyoxide. Are there plans for cohort to implement a minimalistic API? Could be as simple as `https://cohost.org/user -> https://cohost.org/user.json` which contains the same data, but in JSON format.

@voteblake wrote:

How?

This PR makes the following changes:

  • Adds a new claim definition for cohost, relying on the existing HTTP fetcher to retrieve cohost profile pages in text mode.

@yarmo wrote:

Are there plans for cohort to implement a minimalistic API? Could be as simple as https://cohost.org/user -> https://cohost.org/user.json which contains the same data, but in JSON format.

Let me start with a disclaimer that what I'm going to showcase isn't publicly documented API and proper Developer API is in the works: https://help.antisoftware.club/support/discussions/topics/62000183038

However, since it powers the cohost web frontend and it is being extensively reverse-engineered on Github and even on the cohost itself with helpful comments and signs of approval from the original developer themself I believe it is safe to share it and build integrations on top of that knowledge.

Without further ado, cohost is powered by tRPC, and the relevant tRPC call to fetch the user profile (project in cohost parlance) is: https://cohost.org/api/v1/trpc/projects.byHandle?input="{username}"

Using original testing example (https://cohost.org/postl) it becomes https://cohost.org/api/v1/trpc/projects.byHandle?input="postl"
This reveals two potential proof-holding field candidates (marked using JSONPath notation):

  1. $.result.data.description
  2. $.result.data.url

However, those are not the only options. A cursory search for keyoxide site:cohost.org returned following profile: https://cohost.org/srxl aka https://cohost.org/api/v1/trpc/projects.byHandle?input="srxl"
And that further extends the set of candidates with:

  1. $.result.data.contactCard[*].value
@voteblake wrote: > ## How? > > This PR makes the following changes: > > * Adds a new claim definition for cohost, relying on the existing HTTP fetcher to retrieve cohost profile pages in text mode. @yarmo wrote: > Are there plans for cohort to implement a minimalistic API? Could be as simple as `https://cohost.org/user -> https://cohost.org/user.json` which contains the same data, but in JSON format. Let me start with a disclaimer that what I'm going to showcase isn't publicly documented API and proper Developer API is in the works: https://help.antisoftware.club/support/discussions/topics/62000183038 However, since it powers the cohost web frontend and it is being extensively reverse-engineered on [Github](https://github.com/topics/cohost-api) and even on the [cohost itself](https://cohost.org/artemis/post/2353258-started-documenting) with helpful comments and signs of approval from the [original developer themself](https://cohost.org/artemis/post/2353258-started-documenting#comment-a2ae4f59-69d3-433a-8c0f-f10ed61e8516) I believe it is safe to share it and build integrations on top of that knowledge. Without further ado, cohost is powered by [tRPC](https://trpc.io/docs/rpc), and the relevant tRPC call to fetch the user profile (project in cohost parlance) is: `https://cohost.org/api/v1/trpc/projects.byHandle?input="{username}"` Using original testing example (https://cohost.org/postl) it becomes <https://cohost.org/api/v1/trpc/projects.byHandle?input="postl"> This reveals two potential proof-holding field candidates (marked using [JSONPath](https://goessner.net/articles/JsonPath/) notation): 1. `$.result.data.description` 2. `$.result.data.url` However, those are not the only options. A cursory search for [`keyoxide site:cohost.org`](https://www.google.com/search?q=keyoxide+site:cohost.org) returned following profile: https://cohost.org/srxl aka <https://cohost.org/api/v1/trpc/projects.byHandle?input="srxl"> And that further extends the set of candidates with: 3. `$.result.data.contactCard[*].value`

I can see merge conflicts preventing this PR from potentially being merged.

I can see merge conflicts preventing this PR from potentially being merged.
@ -0,0 +1,74 @@
/*
Copyright 2022 Yarmo Mackenbach
Owner
Copy link

We might need to update the year here.

We might need to update the year here.
First-time contributor
Copy link
Not necessarily https://nexb.com/do-you-really-need-to-update-the-copyright-each-new-year/
Owner
Copy link

Therefore the „might" 😼

Therefore the „might" 😼
@ -35,2 +35,3 @@
owncast: require('./owncast'),
stackexchange: require('./stackexchange')
stackexchange: require('./stackexchange'),
cohost: require('./cohost')
Owner
Copy link

Are these sorted perhaps?

Are these sorted perhaps?

@Ryuno-Ki @Mikaela Even if your comments were addressed this PR wouldn't be ready for merging cause it uses HTML scraping instead of the tRPC method explained by my earlier comment. Basically, it needs to be rewritten from scratch...

@Ryuno-Ki @Mikaela Even if your comments were addressed this PR wouldn't be ready for merging cause it uses HTML scraping instead of the tRPC method explained by my [earlier comment](https://codeberg.org/keyoxide/doipjs/pulls/32#issuecomment-1633855). Basically, it needs to be rewritten from scratch...
Ryuno-Ki changed title from (削除) Add support for cohost profile claims (削除ここまで) to WIP: Add support for cohost profile claims 2024年03月03日 15:48:11 +01:00

I prefixed with WIP to prevent merges by accident.

I prefixed with WIP to prevent merges by accident.
All checks were successful
continuous-integration/drone/pr Build is passing
This pull request has changes conflicting with the target branch.
  • src/claimDefinitions/index.js
View command line instructions

Manual merge helper

Use this merge commit message when completing the merge manually.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u cohost:voteblake-cohost
git switch voteblake-cohost
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
5 participants
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!32
Reference in a new issue
keyoxide/doipjs
No description provided.
Delete branch "voteblake/doipjs:cohost"

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?