feat: Invite over internet by RangerMauve · Pull Request #1254 · digidem/comapeo-core

RangerMauve · 2026-03-24T20:58:23Z

awana-lockfile-bot · 2026-03-24T20:58:35Z

`package-lock.json` changes

Summary

Status	Count
	26
	4

Click to toggle table visibility

Name	Previous	Current
`adaptive-timeout`	-	1.0.1
`bare-addon-resolve`	-	1.10.0
`bare-ansi-escapes`	-	2.2.3
`bare-assert`	-	1.2.0
`bare-events`	2.4.2	2.8.2
`bare-inspect`	-	3.1.4
`bare-module-resolve`	-	1.12.1
`bare-semver`	-	1.0.2
`bare-stream`	2.1.3	2.10.0
`bare-type`	-	1.1.0
`bits-to-bytes`	-	1.3.0
`blind-relay`	-	1.4.0
`compact-encoding-bitfield`	-	1.0.0
`dht-rpc`	-	6.26.3
`events-universal`	-	1.0.1
`hypercore-id-encoding`	-	1.3.0
`hyperdht`	-	6.29.4
`hyperswarm`	-	4.17.0
`kademlia-routing-table`	-	1.0.6
`nat-sampler`	-	1.0.1
`record-cache`	-	1.2.0
`require-addon`	-	1.2.0
`shuffled-priority-queue`	-	2.1.0
`signal-promise`	-	1.0.3
`streamx`	2.19.0	2.25.0
`teex`	-	1.0.1
`time-ordered-set`	-	2.0.1
`udx-native`	-	1.19.2
`unordered-set`	-	2.0.1
`xache`	1.1.0	1.2.1

socket-security · 2026-03-24T20:59:08Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	streamx@2.19.0 ⏵ 2.25.0	⁺¹			⁺⁹
	hyperswarm@4.17.0

View full report

…tion

gmaclennan

I left some comments on the approach. I'm not sure the division of responsiblities between the member-api and the remote-discovery class is quite right, but it depends on how you resolve the validation / authentication of incoming connections, which is the most important challenge to address.

gmaclennan · 2026-03-30T05:28:28Z

src/discovery/remote-discovery.js

+    const swarm = await this.#ensureSwarm()
+    const noisePublicKey = Buffer.from(publicKey, 'hex')
+
+    const onConnected = pEvent(this, 'connection', {


Although currently unlikely, we should add defensive code for when the client is already connected to the peer when connectPeer is called.

src/mapeo-manager.js

gmaclennan · 2026-03-30T05:54:48Z

src/mapeo-manager.js

+      identityKeypair: this.#keyManager.getIdentityKeypair(),
+      logger,
+    })
+    this.#remoteDiscovery.on('connection', this.#replicate.bind(this))


This is where we need an authentication guard on the server, validating that the incoming connection has the shared inviteId secret, but also with the manual PIN validation based on the connection handshake hash and verified out-of-band, because otherwise we are giving any incoming connection (which could come from anywhere) access to the RPC channel, which is not secure - it could send invites or other nefarious stuff.

Mind elaborating on the security issues you expect? Inviting internet connected peers to other projects seems like a potential use case in the future.

The attack vector I am concerned about:

I am a remote attacker

I portscan your device, find the open port, and initiate a noise connection.

I can now send RPC messages to your device like DoS invite to project - only the invite-over-internet-redeemed has a check on it.

Of course a similar vulnerability exists prior to this change from an attacker on the local network - our security review picked up on that - however this is a smaller and more acceptable risk.

src/member-api.js

RangerMauve · 2026-03-31T21:03:22Z

I've got the connection and invite flow going. We want to make it harder to track specific peers via the DHT, therefore we want to use a fresh DHT keypair each time. The difficult part is that the keypair is used for the deviceId during the RPC API and that's tied with the member record. We'd need to either tie all members with an additional keypair, or somehow override the deviceID at the RPC layer, or something along those lines.

Gregor proposed we have something like this to send the real identity as the first packet down the noise stream after handshaking.

// Stable identity — persisted across sessions
const stableKeyPair = DHT.keyPair(someSeed)

// Ephemeral DHT presence — rotated each session
const swarm = new Hyperswarm({ keyPair: DHT.keyPair() })

swarm.join(topic, { server: true, client: true })

swarm.on('connection', async (conn, peerInfo) => {
  try {
    const remote = await handshakeIdentity(conn, stableKeyPair)
    console.log('Authenticated:', b4a.toString(remote.publicKey, 'hex'))
  } catch (err) {
    conn.destroy()
  }
})

function handshakeIdentity (conn, keyPair) {
  return new Promise((resolve, reject) => {
    // Sign the Noise handshake hash with our stable key
    const sig = b4a.allocUnsafe(64)
    sodium.crypto_sign_detached(sig, conn.handshakeHash, keyPair.secretKey)

    // Send stable public key + proof in a single message
    conn.write(encodeHandshake({
      publicKey: keyPair.publicKey,
      signature: sig
    }))

    conn.once('data', (data) => {
      const msg = decodeHandshake(data)

      const valid = sodium.crypto_sign_verify_detached(
        msg.signature,
        conn.handshakeHash,  // same hash on both sides
        msg.publicKey
      )

      if (!valid) return reject(new Error('Invalid identity proof'))
      resolve({ publicKey: msg.publicKey })
    })

    setTimeout(() => reject(new Error('Auth timeout')), 10000)
  })
}

This could leave the option to join by remote public key instead of a fresh topic.

We will also need some sort of access control step to have the invite ID before we expose the protomux channel for RPC.

…t.$member.getMany

RangerMauve · 2026-04-02T19:32:35Z

Been wrestling with some sort of race condition for several hours now. I think I traced it down to the protomux channel recieving data before it's fully opened.

gmaclennan

I still think we need an authentication step before connecting to the RPC channel:

Validating the inviteID and allowing the user (invitor) to confirm before connecting, which means queueing the connection somewhere until the user confirms

gmaclennan · 2026-04-06T06:47:21Z

src/discovery/remote-discovery.js

+      }).finish()
+    )
+
+    const data = await firstData


No guarantee this will come as a single chunk. Maybe needs to be length delimited or something? Or rely on it being a fixed length.

Length delimited is probably the safest option. uint32 to be safe?

On the other hand I'm like 99% sure that the first packet will always be a single UDP packet passed through UDX

gmaclennan · 2026-04-06T06:48:29Z

src/discovery/remote-discovery.js

+    }
+
+    // @ts-ignore
+    socket.handshakePublicKey = msg.publicKey


Could just override remotePublicKey to avoid changes in the rest of the code.

Maybe a bit hacky

RangerMauve · 2026-04-08T16:06:50Z

Been blocked getting the tests to work with the handshake logic. Seems the connection is breaking when we try to write the public key down the wire and isn't draining.

RangerMauve · 2026-04-08T16:18:30Z

Might do a flag in local-peers to ignore incoming RPC messages until we get authenticated? I think this extra handshake step is making everything more fragile.

… loss

RangerMauve · 2026-04-08T20:22:21Z

Been trying a bunch of ways to rework this and I'm getting a bit stuck. Gonna write out some thoughts on approaches here.

Initial approach:

Invitor creates invite id
Invitor starts swarm to listen on connections with same identity keypair (with deviceId ad publicKey) as local connections
Invitor sends URL with own deviceId and the inviteId to invitee out of band
Invitee takes deviceID and inviteId from URL
Invitee starts swarm with own identity keypair
Invitee calls "joinPeer" with invitor deviceId and waits for a connection to be established to them
Invitee calls RPC API to send inviteID to the invitor deviceID to redeem the invite
Meanwhile, the invitor was replicating all incoming swarm connections to localPeers and was waiting for an invite redeem call
Invitor runs regular invite flow to the deviceID if the inviteID is valid
Invitee auto-accepts invite if it is from the invitor deviceID
Invitee becomes part of the project

This worked fine

Ephemeral keys approach

Invitor initializes a fresh ephemeral keypair for the swarm
Invitor creates invite id
Invitor starts swarm to listen on connections with swarm keypair
Invitor sends URL with swarm public key and the inviteId to invitee out of band
Invitee takes deviceID and inviteId from URL
Invitee starts swarm with own ephemeral swarm keypair
Invitee calls "joinPeer" with invitor swarm id and waits for a connection to be established to the ephemeral keypair
On both sides we wait for the first "network packet" and fetch a proof for them owning a deviceId keypair (this is their identity key). This Id is used to identify them in local-peers instead of the remotePublic key of their ephemeral swarm keypair in the connection
While waiting for this proof, we generate our own proof and send it down the wire
Invitee calls RPC API to send inviteID to the invitor deviceID to redeem the invite
Invitor runs regular invite flow
Invitee auto-accepts invite if it is from the invitor deviceID
Invitee becomes part of the project

This didn't work because the connection was "breaking" after sending the first packet. I think it's got something to do with how we're reading a packet of the stream before sending it off elsewhere, but it's been really difficult to debug.

Edit: I got this working! I needed to pause the stream after getting the first packet, else we'd drop an event.

Queue up connections before RPC

In order to guard the RPC methods from spam, we should prompt the user to verify them before replicating anything. If we queue up the connections (at the manager level) we need a new place to track them that isn't local peers and would need to somehow tie them to the project they're trying to join via the member API. This extra book keeping and connection management is IMO not ideal. We'd likely need to add the invite ID into the handshake after establishing hyperswarm, which would also mean getting the remote discovery module to ask each project's member-api if this is a valid invite or not. Kinda leaky IMO

Alternate: Disable RPC until connection is verified

Instead we could mark peers inside localPeers as being untrusted which limits which types of RPC events they are allowed to send. We could keep the invite redeem event open and give member-api a new trustConnection(peerId) method which would unlock the RPC channels. On the invitee side we can mark the connection as trusted right off the bat since we validate the remote ID. I think I'll go with this approach first since it's got the least amount of code changes and back-and-forths.

RangerMauve · 2026-04-08T21:22:32Z

TODO: Test all the edge cases

RangerMauve · 2026-04-08T21:23:03Z

TODO: Convert all new Error to proper Error classes inside errors.js

feat: RemoteDiscovery module with Hyperswarm

e8646fd

fix: Connect to correct pear in remote discovery test

2f14b72

RangerMauve changed the title ~~feat: RemoteDiscovery module with Hyperswarm~~ feat: Invite over internet Mar 25, 2026

Mauve Signweaver added 6 commits March 25, 2026 11:48

fix: Update bogon for hyperdht filtering

4255361

test: Fix peer detection in remote discovery

ad6c0be

feat: Connect RemoteDiscovery to member API inviteOverInternet func…

f4a8c84

…tion

feat: Simplify MemberAPI constructor parameters

8e2e3ac

test: Check member API invite over internet properties

039689f

feat: RPC for redeeming invite over internet

b88f0fd

gmaclennan reviewed Mar 30, 2026

View reviewed changes

feat: e2e invite over the internet

f1f0767

Mauve Signweaver added 5 commits April 1, 2026 17:58

feat: Use ephemeral keys for hyperswarm, give real key on handshake

4675bdd

fix: MemberAPI.pendingInternetInvites should return URLs not invite IDs

394facd

fix: Adjust remote discovery tests to use swarm key for connecting

01215f2

fix: Set own device ID for server tests since it is needed for projec…

ad82754

…t.$member.getMany

test: Check that remote connections can send data after connecting

54259c4

Mauve Signweaver added 2 commits April 2, 2026 16:12

fix: Use swarm public key to join project over internet

50eaffb

chore: Clean handle redeem in member api

98b3350

gmaclennan reviewed Apr 6, 2026

View reviewed changes

fix: Pause swarm stream after doing initial handshake to avoid packet…

20203b0

… loss

feat: Do not trust RPC until manual approval for swarm peers

2b227d6

Conversation

RangerMauve commented Mar 24, 2026

Uh oh!

awana-lockfile-bot bot commented Mar 24, 2026

package-lock.json changes

Summary

Uh oh!

socket-security bot commented Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gmaclennan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

RangerMauve commented Mar 31, 2026

Uh oh!

RangerMauve commented Apr 2, 2026

Uh oh!

gmaclennan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RangerMauve commented Apr 8, 2026

Uh oh!

RangerMauve commented Apr 8, 2026

Uh oh!

RangerMauve commented Apr 8, 2026

Initial approach:

Ephemeral keys approach

Queue up connections before RPC

Alternate: Disable RPC until connection is verified

Uh oh!

RangerMauve commented Apr 8, 2026

Uh oh!

RangerMauve commented Apr 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

`package-lock.json` changes

socket-security bot commented Mar 24, 2026 •

edited

Loading