10
45
Fork
You've already forked doipjs
28

WIP: Decentralize Matrix identity verification #26

Draft
yarmo wants to merge 2 commits from matrix-room-verification into main
pull from: matrix-room-verification
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
Owner
Copy link

What?

This PR deprecates the current Matrix verification method as a "legacy method" and adds a new fully decentralized verification method.

Why?

The current method is not a good method as it requires everyone to create a post in a central room, facilitating scraping and requiring verifier libraries to create an account that is a member of this central room.

A new method is needed that doesn't require a central room to work and can be verified by a single API call (with access token).

How?

The new method is similar to the Telegram verification method.

The new method requires people to create a "private (invite-only)" room, set "Who can read history?" to "Anyone" and then add the identity proof to the room's topic. The topic can be read without an account being member of the room.

The v

The new method uses the same configuration as the legacy method.

Issues

When performing the steps described above on matrix.org, it works instantly. The API call looks roughly like:

{
	"chunk": [
		{
			"content": {
				"org.matrix.msc3765.topic": [
					{
						"body": "XXX",
						"mimetype": "text/plain"
					}
				],
				"topic": "XXX"
			},
			"origin_server_ts": 123123,
			"room_id": "!XXX:matrix.org",
			"sender": "@XXX:matrix.org",
			"state_key": "",
			"type": "m.room.topic",
			"unsigned": {
				"age": 123123
			},
			"event_id": "$XXX",
			"user_id": "@Yarmo:matrix.org",
			"age": 123123
		}
	],
	"start": "t8-3301255111_0_0_0_0_0_0_0_0",
	"end": "t8-3301132175_0_0_0_0_0_0_0_0"
}

When performed on my personal Synapse homeserver, and verifying using an account on matrix.org, I get the following error:

{
	"errcode": "M_FORBIDDEN",
	"error": "User @XXX:matrix.org not in room !XXX:otherserver.org, and room previews are disabled"
}

Either I have not properly configured my homeserver, or room previews do not work across instances, which would not be great.

A potential solution would be to have a matrix.org account, create the room on the matrix.org server, invite your account as admin and let that account set the topic.

Downsides to this solution:

  • matrix.org may not be a fan of this behavior
  • it centralizes the verification to a single instance

We need to figure out what the correct configuration is.

Then comes the issue of accounts on instances with admins unwilling to change the config.

A solution would be to set up a dedicated instance (with correct configuration) where we automatically set up rooms and set up the verifiees as moderator so they can set the topic.

Downside: responsibility of hosting and centralization.

TODO

  • Make sure account to verify is the poster of the topic
## What? This PR deprecates the current Matrix verification method as a "legacy method" and adds a new fully decentralized verification method. ## Why? The current method is not a good method as it requires everyone to create a post in a central room, facilitating scraping and requiring verifier libraries to create an account that is a member of this central room. A new method is needed that doesn't require a central room to work and can be verified by a single API call (with access token). ## How? The new method is similar to the Telegram verification method. The new method requires people to create a "private (invite-only)" room, set "Who can read history?" to "Anyone" and then add the identity proof to the room's topic. The topic can be read without an account being member of the room. The v The new method uses the same configuration as the legacy method. ## Issues When performing the steps described above on matrix.org, it works instantly. The API call looks roughly like: ``` { "chunk": [ { "content": { "org.matrix.msc3765.topic": [ { "body": "XXX", "mimetype": "text/plain" } ], "topic": "XXX" }, "origin_server_ts": 123123, "room_id": "!XXX:matrix.org", "sender": "@XXX:matrix.org", "state_key": "", "type": "m.room.topic", "unsigned": { "age": 123123 }, "event_id": "$XXX", "user_id": "@Yarmo:matrix.org", "age": 123123 } ], "start": "t8-3301255111_0_0_0_0_0_0_0_0", "end": "t8-3301132175_0_0_0_0_0_0_0_0" } ``` When performed on my personal Synapse homeserver, and verifying using an account on matrix.org, I get the following error: ``` { "errcode": "M_FORBIDDEN", "error": "User @XXX:matrix.org not in room !XXX:otherserver.org, and room previews are disabled" } ``` Either I have not properly configured my homeserver, or room previews do not work across instances, which would not be great. A potential solution would be to have a matrix.org account, create the room on the matrix.org server, invite your account as admin and let that account set the topic. Downsides to this solution: - matrix.org may not be a fan of this behavior - it centralizes the verification to a single instance We need to figure out what the correct configuration is. Then comes the issue of accounts on instances with admins unwilling to change the config. A solution would be to set up a dedicated instance (with correct configuration) where we automatically set up rooms and set up the verifiees as moderator so they can set the topic. Downside: responsibility of hosting and centralization. ## TODO - [ ] Make sure account to verify is the poster of the topic
Improve claim verification logic
All checks were successful
continuous-integration/drone/push Build is passing
continuous-integration/drone/pr Build is passing
c5a1b2104d
Author
Owner
Copy link

After some more testing, it appears cross-instance room previews are the issue. I can successfully preview a room's topic on my homeserver using an access token from my homeserver.

However, that same access token cannot preview a matrix.org room's topic, the same M_FORBIDDEN error appears.

After some more testing, it appears cross-instance room previews are the issue. I can successfully preview a room's topic on my homeserver using an access token from my homeserver. However, that same access token cannot preview a matrix.org room's topic, the same `M_FORBIDDEN` error appears.
Author
Owner
Copy link

It appears this is the MSC we need to make this PR actually work:

https://github.com/matrix-org/matrix-spec-proposals/pull/2444

MSC2444 allows federated peeking. It appears this issue has been worked on since May 2017:

https://github.com/matrix-org/matrix-spec/issues/245

It appears this is the MSC we need to make this PR actually work: https://github.com/matrix-org/matrix-spec-proposals/pull/2444 MSC2444 allows federated peeking. It appears this issue has been worked on since May 2017: https://github.com/matrix-org/matrix-spec/issues/245
All checks were successful
continuous-integration/drone/push Build is passing
continuous-integration/drone/pr Build is passing
This pull request has changes conflicting with the target branch.
  • src/claim.js
  • src/claimDefinitions/index.js
  • src/claimDefinitions/matrix.js
  • src/enums.js
  • src/fetcher/index.js
  • src/fetcher/matrix.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 origin matrix-room-verification:matrix-room-verification
git switch matrix-room-verification
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!26
Reference in a new issue
keyoxide/doipjs
No description provided.
Delete branch "matrix-room-verification"

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?