Hey,
You are offline? What does this mean? in a local network, not
connected to the internet?
No, I'm not offline. I'm fully online and connected to my server as
usual. I just think to synchronize offline history, which could be a lot
of data and include confidential messages that were initially encrypted,
an encrypted direct client-to-client channel would be cool, both for
speed and security.
Simply upload to http server encrypted.
That seems inflexible. Would work for the simplest use-case (completely
new client wants the full history), but if realistically possible I'd
like to be a bit more flexible. I'd also like to avoid that because it
would mean that your whole history is now available online in one nice
package secured with a single encryption key, so all the effort you put
in beforehand with forward-secrecy etc. would be gone.
XML Stream via Server is not a good way to transfer hundreds of megabytes.
That's one of the reasons I don't want to go over the server but use a
peer-to-peer connection instead :)
Is this about the transport method? Or the format?
Because interoperable format seems like a big task, transport seems easy.
Hah, I would have expected it the other way around. For the format I
could use e.g. MAM, which would give me nice message archive queries and
is supported by the clients I would want to target. The transport seems
difficult though.
I think defining the transport and where to store is useful short
term, then every client can offer their own backup.
It's not really about a "backup" in that sense. For a backup I would
probably do what Andrew suggested and just create a password-protected
zip file with my data and upload that somewhere. The use-case I am
brainstorming is when you get a new client, but you can't get the
history from the server because it either doesn't have complete archives
or some stuff was OMEMO-encrypted. So you quickly scan a QR-code on some
of your other clients and it transfers the local, plaintext messages over.
Regards
Philipp
On Mon, Jul 15, 2024, at 21:55, Andrew Nenakhov wrote:
We're not currently doing it but considering to do in the future.
Very much likely we'll just do an upload of an encrypted archive via
cloud storage. This way it can be interoperable with the likes of
Dropbox / gdrive / whatever.
On Tue, Jul 16, 2024, 00:51 Tim Henkes <[email protected]> wrote:
Hi folks,
I've been brainstorming a mechanism for offline history transfer
(i.e.
one client fetches the offline message history from another
client). For
that, an encrypted direct client-to-client XML channel would be neat.
1. Are direct client-to-client XML channels a thing?
I found XEP-0247 [1], which looks alright on first read-through
but is
deferred since 2010. Does someone more familiar with the topic
know why
the XEP was abandoned and whether it could realistically be
revived or
if there is a better alternative now?
2. Are encrypted direct client-to-client channels a thing?
There is JET [2], but it seems to focus on key negotiation (which I
would do differently) and file transfers, which I don't need
either. I
don't see how a bidirectional data channel/stream would be encrypted
using JET.
There's also a XEP called jingle-xtls [3] in the Inbox, but it's even
more abandoned than XEP-0247 and also seems to focus mostly on
the key
negotiation, which again I would do differently.
Next to these questions I would be interested in the general
sentiment
and ideas for workarounds (e.g. "p2p is cursed, just send encrypted
stanzas via the server as usual" or "just use a simple binary
format and
don't bother with a fully fledged XML stream").
Thanks :D
Tim
[1] https://xmpp.org/extensions/xep-0247.html
[2] https://xmpp.org/extensions/xep-0391.html
[3] https://xmpp.org/extensions/inbox/jingle-xtls.html
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Standards mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
