RoxyCloud has one deployment shape today: the server owns the bytes. Devices talk REST to it, it
keeps the blobs, the node tree, the quotas. That is the Nextcloud shape, and it is the wrong shape
for a common case, which is two or three machines that belong to the same person and want the same
folder on each of them without a copy living on a server in between.
Syncthing is the shape for that case. This is an RFC for supporting both, not a decision.
The idea worth testing first
Not "two products in one repository". A device is a peer that holds a replica of a folder, and the
server is a peer that happens to be always on. Which mode you are running is then one policy on that
peer:
| Mode |
The server |
What it can offer |
store (today) |
Holds every blob |
Web app, WebDAV, share links, quotas, trash |
sync |
Holds no blob, carries device introductions and folder metadata |
Device-to-device transfer only |
If that framing survives contact with the code, the two modes share the node tree, the reconciler
from #21 and the wire format, and differ in whether the server keeps what passes through it. If it
does not survive, the honest answer is that this is a second product and it should be said out loud
before anyone writes the code.
What the content-addressed store already buys us
A block exchange protocol needs stable content hashes, a way to ask a peer which blocks it has, and
dedup on receipt. crates/core and the blob store already have the first and the third. That is the
strongest argument that this is one foundation rather than two.
What has to be answered
Device identity. Session tokens are wrong here: there is no server in the loop to issue them.
Sync mode needs a per-device keypair and a device id both ends can pin, the way Syncthing does it.
That is a third authentication path next to passwords and the app passwords in #10, and it is the
part most likely to be got wrong.
Discovery and reachability. LAN discovery covers the easy case. Two machines behind different
NATs do not connect on their own, so either the deployment accepts "must be reachable", or something
relays. If the server relays, it sees the traffic, which puts encryption between devices on the
critical path rather than in v2 where ARCHITECTURE.md currently files it.
What is simply absent in sync mode. Share links need bytes somewhere. WebDAV needs a host that
holds content. Quotas are a statement about server storage. Trash and restore need a copy that
outlives a local delete. A mode that quietly degrades these is worse than one that says up front
which half of the product it is.
Conflicts. Already decided: keep both, rename the loser. Peer-to-peer makes them more frequent,
not different.
Scope, if it goes ahead
A first cut is not Syncthing. Something like: explicit device ids pasted between two machines, no
discovery server, direct connection only, one folder, no relay, no encryption beyond the transport.
Enough to prove the peer framing, small enough to throw away if the framing is wrong.
Blocked on
#21 is written against a remote tree served over REST. Whether its reconciler is reusable against a
peer decides whether this is a variation or a rewrite, so #21 should land, or at least be designed,
before this is scoped further.
RoxyCloud has one deployment shape today: the server owns the bytes. Devices talk REST to it, it
keeps the blobs, the node tree, the quotas. That is the Nextcloud shape, and it is the wrong shape
for a common case, which is two or three machines that belong to the same person and want the same
folder on each of them without a copy living on a server in between.
Syncthing is the shape for that case. This is an RFC for supporting both, not a decision.
The idea worth testing first
Not "two products in one repository". A device is a peer that holds a replica of a folder, and the
server is a peer that happens to be always on. Which mode you are running is then one policy on that
peer:
store(today)syncIf that framing survives contact with the code, the two modes share the node tree, the reconciler
from #21 and the wire format, and differ in whether the server keeps what passes through it. If it
does not survive, the honest answer is that this is a second product and it should be said out loud
before anyone writes the code.
What the content-addressed store already buys us
A block exchange protocol needs stable content hashes, a way to ask a peer which blocks it has, and
dedup on receipt.
crates/coreand the blob store already have the first and the third. That is thestrongest argument that this is one foundation rather than two.
What has to be answered
Device identity. Session tokens are wrong here: there is no server in the loop to issue them.
Sync mode needs a per-device keypair and a device id both ends can pin, the way Syncthing does it.
That is a third authentication path next to passwords and the app passwords in #10, and it is the
part most likely to be got wrong.
Discovery and reachability. LAN discovery covers the easy case. Two machines behind different
NATs do not connect on their own, so either the deployment accepts "must be reachable", or something
relays. If the server relays, it sees the traffic, which puts encryption between devices on the
critical path rather than in v2 where
ARCHITECTURE.mdcurrently files it.What is simply absent in sync mode. Share links need bytes somewhere. WebDAV needs a host that
holds content. Quotas are a statement about server storage. Trash and restore need a copy that
outlives a local delete. A mode that quietly degrades these is worse than one that says up front
which half of the product it is.
Conflicts. Already decided: keep both, rename the loser. Peer-to-peer makes them more frequent,
not different.
Scope, if it goes ahead
A first cut is not Syncthing. Something like: explicit device ids pasted between two machines, no
discovery server, direct connection only, one folder, no relay, no encryption beyond the transport.
Enough to prove the peer framing, small enough to throw away if the framing is wrong.
Blocked on
#21 is written against a remote tree served over REST. Whether its reconciler is reusable against a
peer decides whether this is a variation or a rewrite, so #21 should land, or at least be designed,
before this is scoped further.