[Feature]: Internet Hop when no one is around

[DeathfireD]

Problem / motivation

Since this app is in its early stages it will take a very long time for a message to go from one user to another to its intended target if they are not all within the same area. Which obviously isn't a problem for when you use this at a concert or convention, however if it was for situations where you wanted to message your friend in the next town over, or at the bottom of the mountain 7 miles away, the message would take forever to get there. The idea of holding on to an encrypted message until coming into contact with another user using the app and then passing it on is great but again, not enough people use the app yet.

Proposed solution

My proposal would be to add an option to give the app the OK to relay the message over internet if you don't come in contact with another local user for the next xyz minutes. The original writer would check off a box to allow their message to be relayed over the internet and recivers would need to have the option in settings enabled to relay messages over internet after xyz minutes turned on. This way those that want to strictly use this offline can and those that are OK with using it for both offline and internet use can as well.

Ex.
If a user does not have the "relay message over internet" turned on then the app sticks with its default behavior.

If a sender checks the "OK to relay messages over internet" checked and they don't have internet, the message gets sent out to local users using the app. If one of those users has the setting turned on to relay over internet, then the message will be relayed over internet after xyz minutes ONLY of the writer gave permission for their message to be relayed over internet.

Hopefully that makes sense. I'm not sure how you'd handle duplicate messages coming from multiple sources...etc

Alternatives considered

No response

Scope and mesh impact

• Changes the CBOR wire format
• Changes store-and-forward custody / convergence
• Changes the end-to-end crypto envelope
• None of the above / not sure

Additional context

No response

Before submitting

• I searched existing issues and this is not a duplicate.
• I read the support expectations and roadmap, and understand some scope is deliberately deferred.

[zaventh]

I've been thinking about this one for a long time and there's a design draft in my notes. What I won't do is turn Knit into another Signal with a mesh mode on the side, so no accounts, no directory, no server-side identity. The offline design doesn't move either: the mesh stays the default, and the internet path is off unless you switch it on.

What I'm looking at is a small relay protocol. Tiny self-hostable daemons holding sealed blobs for a conversation they can't read or identify, several at once from a list you can edit. A phone that pulls from one re-floods it onto the local mesh, so one connected member bridges a whole radio island.

Duplicates are already handled: frames are content addressed, there's a seen-set, and acks are idempotent.

Prerequisites come first either way, and they're on the roadmap anyway: a ratchet for forward secrecy, group key state, encrypted receipts. The relay addressing derives from the ratcheted secret, so there's nothing to build on until that lands.

No timeline. Leaving this open as the tracking issue.

[github-actions]

Thanks, @DeathfireD — this is real, and it's deliberately deferred rather than overlooked.
The Roadmap in the README and CONTRIBUTING.md
cover what's parked and why.

Leaving this open as the tracking issue. No timeline attached, and it's exempt from the
stale bot.

[DeathfireD]

I've been thinking about this one for a long time and there's a design draft in my notes. What I won't do is turn Knit into another Signal with a mesh mode on the side, so no accounts, no directory, no server-side identity. The offline design doesn't move either: the mesh stays the default, and the internet path is off unless you switch it on.

What I'm looking at is a small relay protocol. Tiny self-hostable daemons holding sealed blobs for a conversation they can't read or identify, several at once from a list you can edit. A phone that pulls from one re-floods it onto the local mesh, so one connected member bridges a whole radio island.

Duplicates are already handled: frames are content addressed, there's a seen-set, and acks are idempotent.

Prerequisites come first either way, and they're on the roadmap anyway: a ratchet for forward secrecy, group key state, encrypted receipts. The relay addressing derives from the ratcheted secret, so there's nothing to build on until that lands.

No timeline. Leaving this open as the tracking issue.

Thanks for the detailed run down. Glad it's not overlooked. I'm sure you've already looked into it but could you use mqtt? I belive meshtastic or meshcore utilize mqtt if enabled.

Anyway, I'm excited to see where this project goes. As an outdoor enthusiast, this seems like a promising project.

[zaventh]

The thing you asked for is in a test build, if you want to try it: https://github.com/getknit/knit/releases/tag/v2.3.0-alpha.0

A relay is really just a Knit node that lives in the cloud rather than in someone's pocket. Same sealed-blob ferrying a phone does, except it's always reachable. It can't open what it holds or tell who it's for, and there's no account behind it. It does see your IP and roughly when and how much you sent, and the app says so before you switch anything on.

Relays stay off until you turn them on. One difference from your version: the opt-in is per-app rather than per-message, with no timer. Radios first, relay only when nothing nearby can carry it.

It's an alpha and isn't on F-Droid, so grab the .apk from that page and open it on your phone. If your Knit came from the Play Store it won't install over it, since Google re-signs those with a key I don't have, so you'd uninstall first and lose your messages. From F-Droid or GitHub it installs in place. Either way there's no going back to 2.2.3 without uninstalling.

No obligation. If you do try it, what I'd like to know is whether a message actually arrives when nobody's in range.

[DeathfireD]

I tried it with a friend who is not presently near me and it did not work. Do we both need to scan each other's QR codes while being in the same room or does the QR code contain the current IP when you have internet relay turned on? It would be nice to be able to add people without having to be in the same room when the person is ok with using the internet.

Second thing I noticed. When scanning QRs, it does not use our new Nick Name. It uses whatever the default name was when we opened settings. So in chat it asks if you want to talk to magpie.

[zaventh]

I tried it with a friend who is not presently near me and it did not work. Do we both need to scan each other's QR codes while being in the same room or does the QR code contain the current IP when you have internet relay turned on? It would be nice to be able to add people without having to be in the same room when the person is ok with using the internet.

Second thing I noticed. When scanning QRs, it does not use our new Nick Name. It uses whatever the default name was when we opened settings. So in chat it asks if you want to talk to magpie.

That is correct; you'll have to have exchanged keys in-person essentially (technically doesn't have to be direct radio link, but over the radio mesh). It's a little complicated but this is for security and privacy reasons. Since there is no authoritative server, no accounts, etc. this is how identity is controlled -- by the users physically participating in the mesh.

[DeathfireD]

Gotcha, I won't be able to actually test until probably the weekend then.