XSF Discussion - 2020-12-28

Here is an example how I would do an export / client migration: https://paste.centos.org/view/b09f3029

I use the <delay> element to store the message time

isn’t there a XEP for that?

Of course, lot's of omemo infos are missing

ah, client side

client side, yes

"stuff you only need with strange E2EE" :-X ✏

I would call it "State of the art E2EE in IM"

:D

Still, you need that without e2ee too

marc stanza-id needs to be in there

this means i need to save every message so i can convert it back to xml

for example i dont save the resource from which the message came

never had the need for that

lovetox, okay, good point

Dino stores that information

lovetox, isn't the id attribute the stanza id?

it's not

maybe it was clearer when it was called archive-id

ah, okay

what's the reason not using the id attribute as uuid?

This feels like one of the recurring discussions we have. I'm hoping the reasoning is written down somewhere.

No, I don't want to discuss this. A pointer to the reason would be enough :D

historically, there is no guarantee that the id attribute is sufficiently unique

MAM archives need a unique id to reference stored messages. The id attribute is not guaranteed to be present or unique (it is controlled by the sending client)

Early versions of XEP-0313 added an element: <archived by='[address of archive]' id='[archive id of message]' />

Then it was decided that it would be generally useful if other XEPs could use these guaranteed unique ids as well, so it was split out to stanza-id

The id attribute remains useful to the sending client as a way of tracking error responses (kind of), but for long-term unique identifiers, stanza-id is the preferred way to refer to a stanza

origin-id was added to the stanza-id XEP as a hacky workaround for certain MUC services that did not preserve the 'id' attribute on messages, but I sense that most people would like to see that to be removed now

Errors having the same id as the stanza they are an error-reply to makes @id non-unique..

true

In a backup it would make some sense to stick <stanza-id by="local client full jid" id="whatever primary key of local database"/> in there

Althoooooo

You need (@from, @id) for uniqueness in any case, and errors would have @to/@from swapped.

Ah, thanks for the explanation

New version that generates <stanza-id> elements and omits to/from for the own account: https://paste.centos.org/view/75801e0e

Zash [17:16]: > In a backup it would make some sense to stick <stanza-id by="local client full jid" id="whatever primary key of local database"/> in there But what if your local database is using auto increment integer?

What about it?

A stanza-id must be globally unique

Does it?

It's still scoped by stanza-id/@by, no?

Oh, right!

So it doesn't guarantee the one thing it was supposed to fix about @id

Despite the title

You had one job, XEP-0359

> It is RECOMMENDED that the ID generating service uses UUID

today I learned something new, that XMPP is a "store and forward" protocol which makes it unsuitable for messaging

however, Signal *is* suitable for messaging

I'm waiting in suspense for the explanation, but I'm guessing it'll never come

moparisthebest we should make XMPP over Signal Protocol then, should solve this problem

he responded, many XEPs are in draft and he was in a big company once and the user list made xmpp "fall over"

don't get what this has to do with Signal but oh well

why do I even talk to people on the fediverse lol

time to build a social network on top of XMPP !

I remember some xeps.xml file listing every XEP published, do you remember where it is?

It got replaced by something with a slightly different format

xeps-list.xml or somesuch?

Link Mauve, https://xmpp.org/extensions/xeplist.xml

Thanks. :)