XSF Discussion - 2017-03-20

I’m not an XML Schema guru, but we’re currently looking at the schema for XEP-0084. It appears to me that it doesn’t allow any attributes for <pointer/>, but in the text it is specified that pointer MAY have some attributes (those already specified for <info/>).

jonasw, Our schemas are often rubbish, yes. In the case of the <pointer/>, I take it you're interested in implementing this? I don't *think* anyone else has.

not really

just a stub

well, we’re implementing XEP-84, but not <pointer/>, to make it clear

I'd be inclined to strip <pointer/>, even if it's Draft, to be honest. I can't see how it's interoperable.

I find it a bit annoying that one can only save image/png in PEP there

I understand and welcome that image/png is required, but from my reading the XEP explicitly forbids anything but image/png in the :data node :(

Only when only one node is supported, like how some popular implementation(s?) do it.

what do you mean?

Zash, No, I think the text as written restricts the <data/> element to be image/png only.

What

yes

Where?

Zash, §4.1

-xep 84

> The XML character data MUST represent the image data for the avatar with a content-type of "image/png", Base64-encoded in accordance with Section 4 of RFC 4648 [10]. (Note: Line feeds SHOULD NOT be added but MUST be accepted.)

Zash: XEP-0084: User Avatar (Standards Track, Draft, 2016-07-09) See: https://xmpp.org/extensions/xep-0084.html

Is that new?

hopefully not. this is a MUST and the XEP has been in draft since 2008 or something :)

2007 even

Changed in 2007, just before Last Call.

Version 0.12. Or at least, that's when the line was edited.

I thought that it said "If only one item is published, it has to be PNG. Other items can be whatever."

Oh, mind you, "The XML character data MUST represent the image data for the avatar with a content-type of "image/png"", edited in 2007-02-23, which doesn't appear in the version history.

But since in practice you are going to have a hard time publishing multiple items...

The png-only text shows up in https://xmpp.org/extensions/attic/jep-0084-0.7.html#proto

wait, if PEP won’t allow more than one item the XEP has a data race

Wasn't there a feature for that?

dwd: let’s keep <pointer/>

it may be useful if we ever want to extend XEP-84.

saves a replacement.

fippo, what's google meet? their new duo?

Yet another Google messenger?

https://meet.google.com/

maybe a gotomeeting like thing from google?

https://techcrunch.com/2017/02/28/google-quietly-launches-meet-an-enterprise-friendly-version-of-hangouts/

yes, more or less

whereas the other is more like a Slack/HipChat

they got an alternative to Slack/hipchat?

Hey, while we are talking about Slack. If you slack a message to yourself, it's just stored on the server and reflected to your other devices. In XMPP (with Carbons), every one of your devices has two copies in the end

Would it be sensible to change Core routing / Carbons to only deliver the message to your _other_ clients?

or is this something that should be handled in the client?

Ge0rG, marginal case, as I guess? or is there real use?

Ge0rG, MAM should be the source of truth, not?

nyco: I'm messaging myself all the time (URLs to my mobile etc), and I'm using a secondary JID because duplicates look bad

Tobias: MAM will obviously also contain two copies

Tobias: the incoming and the outgoing one

Ge0rG, yeah?

so why not store those things in a private pubsub node?

Ge0rG, maybe there could be a mention of it in MAM to allow server to optionally remove that one duplicate

nyco: because every client supports messaging, and no clients support private pubsub nodes.

Tobias: that's not so easy.

Tobias: MAM is only if you come online later on. Carbons / core 6121 is when you are online

Which is one of the reasons I'm insisting on making MAM-subscribe a thing.

Ge0rG: that's what M-Link does. Messages to self are archived just once.

And, as a result, returned just once.

intosi: are carbons of messages-to-self also inhibited?

Carbons are not archived.

intosi: if I'm online with /A and /B, and I send a message from /A to bare-JID (or even to /A), which client will receive how many copies again?

And messages to self follow the normal carbons rules. Only interested clients that aren't snders or recipients already will receive them,

intosi: because a message-to-self is two messages in most cases :>

and from my reading of 6121+Carbons, you can't strip out one of them without violating the protocol

I'll probably regret asking immediately, but why?

intosi: an incoming message must be delivered to a subset of the available resources by 6121, and to all other resources that have carbons by 0280

intosi: and an outgoing message must be carboned to all other carbon-enabled resources

Yeah, sure. And you're claiming a server must do both sent and received handling separate?

from a technical PoV, a message to self is first an outgoing message from your sending client, and then an incoming message to wherever it was addressed

I chose not to do that, it's stupid.

intosi: actually I'll gladly accept a different reading of the RFC, but it seems like you were the only one to do the "right" thing, and I'd be surprised if it's backed by the RFC

tobias: video hangouts with a new interface. watch https://www.youtube.com/watch?v=8a-mmT9ifss if you're interested

fippo, ta

It followed from my reading of 280, interpreting it as a hint on which resources should receive the message. It makes no sense at all to handle the sent and received carbons separately when from and to are the same account.

On which resources, apart from normal RFC routing, I mean.

intosi: you are right of course. But even normal RFC routing is convoluted in this case.

Didn't touch RFC routing rules at all.

intosi: if you don't touch RFC routing, you'll end up in an even weirder place. Imagine that RFC routing rules require you to send the message back to the sending client.

Then the sending client will end up with two copied, and every other client with only 1.

Ge0rG: perhaps in your code base.

intosi: no, RFC 6121 is very clear on this. https://tools.ietf.org/html/rfc6121#section-8.5.2 and https://tools.ietf.org/html/rfc6121#section-8.5.3

there is no "you can ignore the sending JID of self-messages" exception

I wish there were.

I'm probably too stupid to understand what your problem is.

Ge0rG: So you are saying we can't add a sentence to 280 that carbons of self-messages should not be send to the sending resource?

intosi: I want to ask my favorite server's developers to reduce the number of self-messages from 2 to 1, but RFC6121 disallows that.

Flow: no. I'm saying that, carbons-aside, you'll end up with partial message duplication based on 6121.

Flow: this can't be fixed in carbons only. And if we try, we'll end up with {1..2} messages arriving at different clients

Hmm, I think I don't have the whole picture of the problem. Maybe post to standards@?

But then again, I also think that 6121 bare-JID routing rules are fundamentally broken for the IM use case.

Flow, lovetox, intosi: https://mail.jabber.org/pipermail/standards/2017-March/032421.html

Ah, now I understand you. Yes, foo/A sending to foo will result in a copy to self.

See, I'm too stupid to understand your words.

intosi: I'm too stupid to find the right words to make the problem accessible

What will not happen, is sent carbons to be generated, even if you send to a bound JID foo/B.

intosi: feel free to comment that you won't violate 6121, and that my claim of such is a blatant lie

Like I said, I didn't touch core routing rules for carbons. Not delivering the message to self when insisting on an unbound bare self jid would violate the RFC.

Anyway, sensible clients bind to a full jid as soon as they can anyway.

intosi: resource-binding only adds to the uncertainity

sensible clients should always send to bareJID because the server knows better which resources are there.

the only exception is OTR, which is considered generally broken.

I disagree, except for the OTR bit.

Ge0rG, "always"?

dwd: yeah.

https://xmpp.org/extensions/xep-0296.html

dwd: following that XEP leads right into madness land.

It would be so nice if that idea worked out in practice ...

dwd: just consider the race conditions between sending a message to a locked JID and that locked JID disappearing.

Things are getting even funnier if you change client behavior based on the locked JID's supported features.

You start typing a LMC correction, but then another client of your buddy comes online, you get unlocked and your client refuses to LMC.

..or doesn't ask for a 0184 ack.

And I don't even want to get started about different message routing rules, which cause a "real" message vs. a carbon to arrive at your destination.

You seem to have got started on the thing you claim you don't want to get started on.

Seriously, we need to reconsider all that and just say that unless explicitly required, all messages should go to bare-JID, because we want to talk to the "account" and not to the "client".

dwd: no, I didn't. Carbons are a whole different can of worms.

Ge0rG: I believe any sensible client does already that

Flow: does what?

Flow: intosi> Anyway, sensible clients bind to a full jid as soon as they can anyway.

Ge0rG: But with carbons on both ends, where is the issue when performing resource locking?

Flow: see above.

Flow: also, if the receiving client goes offline, even with carbons, the server will generate error responses for the queued messages

fair point, but you don't have to convince me. If I where to write an XMPP IM client I would probably always send messages to bare JIDs

because most of the features supported by yaxim fail safe, and because it doesn't support many features, it works out excellently.

CAPS?

Flow: 0030/0115

so is there any use case for https://xmpp.org/extensions/xep-0201.html except the ones described in the xep, because i dont really feel i dont need the ones described in the xep

lovetox: actually, those use cases are awesome. the problem is only that noone has ever found a good UI for them.

they feel like "look what we could do if somebody would find some use case for this"

I'd love to be able to collapse threads I'm not interested in. But that would require XMPP clients to actively mark messages with the correct thread-id

+1 Ge0rG

haven’t had a good idea yet, unfortunately

I'm actually thinking about adding a thread-ID in yaxim when you tap on a nickname to do nickname completion

not sure that’d perform well

jonasw: it would probably cause gazillions of false-positives, but then again: no sane client relies on thread-ids to mean anything :P

you mean in a muc

lovetox: yeah

so that you tap a button and start a new thread

and how does the other client respond to the thread?

with tapping I can actually imagine that this would work

lovetox: no. you tap on a message to continue that thread

I cannot imagine how that works in a desktop application

as soon as you have multiple threads with overlapping participants :(

jonasw: also tab completion :P

Ge0rG: see above

with yaxim you could use the thread of the message which the user tapped at for completion

and then reorder messages so messages from threads are grouped?

maybe

maybe one could add colors to message threads

as a subtle hint

like this? https://wiki.xmpp.org/web/Contact_Colors

anyway, I gotta run.

jonasw: yeah, nickname --> text color; thread --> bg color

severe eye injury!

ouch

so for muc i feel this is not too hard to implement

its just the ui how you respnd

or switch thread

yes, the UI is hard

exactly

unfortunately; because I think it could add a lot of it worked magically

that would intuitively work for pseudo-forums, but not for IM

wtf

there needs to be a feature, that lets me add a name to the thread

the wiki dropped my non-latin1-characters

what the heck

so then someone could hit a key and cycle the thread names

and write to the one he wants

lovetox: why names? just use <Tab> to color-highlight the threads one by one.

can we just add a name tag to the thread element

Or maybe... Meta-Tab, because Tab is already used for nick completion :P

on desktop i have endless possibilities with shortcuts i dont see a problem with that

lovetox: yes, but your users don't have infinite memory for shortcuts

right

so the client automatically gives a color to a new thread

this is IM, not blender

this can get tricky in a muc with much threads

names are better i think

names requires extra user interaction

-> won’t be used

lovetox: MS Teams has multiple input boxes per thread level. The one in the bottom starts new threads, and then there is a box in each thread at each level, to allow answering there

hm, interesting approach, too

but to be honest, on a smartphone, a muc is cramped already

on desktop this could be a really nice feature

i mean you have space for 3 messages on a smartphone ^^

I have enough space for five

threads or not, you will not have a sense of overview in a muc on a smartphone

especially not one where much goes on

depends, if the threads are properly done and you view only those you are interested in…

but I doubt that will work reliably, because users will accidentally post messages in the wrong thread

interesting question: can LMC modify the <thread/>?

yeah, collapsing / ignoring threads would be awesome on smartphones

"The Sender MUST NOT include a correction for a message with non-messaging payloads." - looks to me like it's not forbidden

fg

What? Hey!

yeah pretty nice idea for threads

but i see this more as a feature for serious work groups etc

not for your everyday muc

lovetox, indeed

on desktop you could capture all threads put them into a list

let the user name them

If done right, it could work for both

on click open a tab that displays only msgs from that thread

that way i also know to which thread a user wants to respond

But then, there will be the one client that fails, the Outlook of XMPP, the Pidgin of Carbons, where it's just plain broken

i just treat it like a new conversation

yeah Ge0rG thats why i said its probably only for serious groups

that know what they are doing

lovetox: rule number 1 of interface design: users don't know what they are doing

that

Ge0rG, on the topic of self messaging

receipts have no use in my opinion

on sent message if you dont get a error stanza from the server, you can see it as delivered

it doesnt matter if your other client is online and sends a received stanza..

right, stream management tells you that it has been processed by the server

i dont know when i ever would need that info

i mean if you client is not totally broken you will get that message via MAM or offline message or carbons or whatever

you’d want to be sure that you can find it in MAM later

for this you need to make sure that the message actually makes it to the server

-> SM

lovetox: see, some client developers can't even send a coherent message with a highlight, how are Normal Users supposed to manage threads? 😀

so i think i will deactivate receipts for self messaging, its only noise

lovetox: sounds good enough to me.

chatstates dito

Yeah, ideally 0198 will manage the thing. However, I'd still like to show green checkmarks, just maybe with a different logic to create them.

Ge0rG: SM should be a sufficient source for that, no?

yeah though, in most cases i dont have events for sm stanzas in my application, and its maybe not so easy to link them to messages, for example my first idea would also be just to use the "sent" carbon that i get as a receipt

at least in gajim that would be way easier then to do this via sm stanzas

lovetox: no 'sent' receipt on outgoing message

fippo, regarding that video..."you want ford be able to call general motors, etc." that all sounds like a nice fit for a federated system, but then again it's google

Ge0rG, then the received ?

that we want to get rid off ^^

lovetox: Yeah, unless you're on mlink

tobias: well, meet. doesn't work in Firefox anymore than hangouts does...

see now would be cool when we could join our own thread Ge0rG :D

hangouts requires a plugin in FF anyway, not?

well, npapi died.

lovetox: Yeah. Good luck getting that UX sorted out and introduced into all Jabber.. No, XMPP clients.

maybe i do it once just for fun, i think gajim has already everything set up for it, window manager, thread managing, it just needs to be connected and a little bit of UI :)

i doubt that it is "a little bit of UI", but sure. make a nice demo, I’d be interested in how this can work nicely

i described it above, i would gather the different threads and display them in a list

when the user clicks that list, a window opens where the messages are filtered with the thread

This might also not be the biggest problem that gajim has...

if he writes into that window, message goes to the thread

seems pretty easy

on desktop i dont have to put everything into one window :)

yes you have.

(but that is just my humble opinion ;-))

dont limit the desktop to a bigger smartphone :)

don’t litter my desktop with windows

i actually dont, i can also use tabs inside one window ^^

What happens if I'm in a client that doesn't support threading and I reply to the discussion, then other people reply to me? It probably doesn't show up in your tab, and then you only see half the discussion and the thread is broken.

yeah SamWhited of course you can sabotage it .. but if only gajim clients talk with each other it would work good :)

and maybe others adopt it

:)

that’s not sabotaging, that’s simply interoperating

I read that as "so it will never work"

or rather not interoperating

I'd love to see the UX issues around threading worked out; I've thought about this a lot and never been able to come up with a good way to do it that didn't just break constantly.

but the breaking has nothing to do with your UX

it has to do with other clients

You just add a context menu "join with thread" that opens a sub menu with a list of all threads

SamWhited: however, in lovetox’ defense: you will never be able to interoperate with clients which do not do threading properly. that’s simply how it is, it’s the same for email.

It doesn't matter; there will be other clients in the chat, and if they break the threading on my end and I'm a user all I know is "threading is broken, this is bad"

indeed

somebody has to start

yes, it’s tricky

it would be good if one could somehow sanely detect these clients and fall back to a sane non-threaded UI for those

or rather if those clients participate

Or you'll end up with implausible requirements similar to OMEMO/MUC. All of the participants need to implement "Easy XMPP" and you need to have them in your roster for threading to work.

Now you have a UI inconsistency between rooms that have some other client joined, and rooms that don't, which also feels poor (maybe better, maybe worse? I'm not sure)

as i said i would just show a list with all threads, you dont have to click them and join, you can just watch the muc like now ..

its just a addtional tab when you want to use it and it works

SamWhited: I think it’s better, because it is a more or less sane upgrade path to a world where all clients can do that

Also between the same room on one day and the same room 10 minutes later

ugh

it’s all a mess.

When I'm in a room, and a client that doesn't support threading joins, do all my threads just close? That will feel poor

on a related matter: a XEP which allows me to post a simple reaction to a post would be great

I’ve seen that with slack I think. or like you can on github issues

those wouldn’t trigger any UI notifications, and it saves vertical space

https://xmpp.org/extensions/xep-0367.html ?

SamWhited, why would a thread close? the messages have that thread on them and i can filter the window for it, it doesnt matter what another client does, except spamming my thread maybe

Yah, that's one of the things we were going to use 0367 for, although it's not called out explicitly and I don't think it's happening now

SamWhited: do it like youtube "User XY does not have threading, thus we have to fold it all. We are sorry. (Blame them and hunt them with pitchforks & torches)"

ah cool, SamWhited

I was already thinking about 367, but it seemed to be too broad for that. if it is intended to serve that purpose, great!

lovetox: But now when that user replies, your threads break and we're back to the beginning

Somehow, my smartphone miscompleted roster into rosette...

why would it break? what does breaking mean for you?

adding a message that doesnt belong to the thread is breaking?

lovetox: not correctly showing semantically related messages all the time

yes.

that’s breaking.

Their messages don't show up in the thread, and people are replying to the conversation both in the threaded room and in the non-threaded room

SamWhited: it'd also need message retracted to do the full reaction UX, but yeah that's what I had plans for with 367 too

now the thread is split between two places

so when i go to a message board and post in the wrong topic, i broke the topic?

Lance: ah yah, good point; we never actually got that far

yeah that people answer to it with the wrong thread on the message, ok

that is a problem in the start

that the filtering is not good

but it would get better and better as more clients adapt

this does not even mean implementing the same thing

just use some sane rules on threads

It's nto that people are posting to the wrong topic though; a message board will show everyone a consistent view of what the topics are. It's juts that users are posting the only way they can, and it's breaking the thread for some users but not others.

lovetox: in 20 years, there will still be people on the xsf MIX using Pidgin.

i bet i get Ge0rG and inputmice, Link Mauve , mathieui and probably one or two other devs to not break my shiny new thread feature

and we ban the rest from all mucs :D

lovetox: on mobile, people will just tap on the first instance of the person they want to complete.

And you really really really don't want to promote lightweight threads to windows

I tried a web chat thing recently that did threads as windows; I thought it worked pretty well, the only problem was that it also kept the threads in the main chat view, which meant everyone just replied in the main chat view and the threads never got used

SamWhited: sounds like slack

UI for naming the threads then use tab completion

I haven't actually tried Slack since they introduced threading

lovetox: It's still more work than just typing your message and hitting enter, which means most people will ignore it

SamWhited: I was the only one to try threading, so I consider it a UX failure

not everything has to be used by everyone

Ge0rG: Yah, that's how I was with this messenger (I forget what it's called) that our team was playing with

lovetox: it does in this case, otherwise the threading is always broken and worthless

everyone or at least most people

lovetox: you would need to provide visual hints, like color codes for the U to work out

That's what this did, which was actually rather nice, let me ask what it was called…

ok what about this

a work feature: there is no main chat view

only a add thread button

every thread gets his own window

you can only answer to threads

Isn't taht just making new mucs at that point? (also, that still requires every client to do it)

when you join you load mam, and get automatically a list with all threads

lovetox: Yeah, will be broken immediately by an incompatible client

thats why i said its a work feature

like a company if they all use the same client

And then some client will use auto increment integers for threads ids

making a new muc has considerable overhead

yah, fair enough, it can work in closed environments

actually is that not exactly what we need for mailing list replacement ^^

a search function added and its perfect

and its all archived in one single muc :D

"Sending of MUC messages without a thread ID is disallowed by group policy. Please contact your chat administrator."

lovetox: and you only can get the last 50 messages.

CA Flowdock is the thing we were looking at that did threading, btw; might be worth experimenting with if you're trying to do this: https://www.flowdock.com/

It was pretty nice looking, but when we tried it no one used threads, so I felt like it was a failure.

Or rather, one person did, and everyone else replied in the normal chat and then they didn't see replies in the thread

SamWhited: maybe they were using the xmpp transport? 😀

so lets recap this, instead of the participant list in the muc i show a thread list, the client has MAM so gets all backlog, the muc is moderated, only people with voice can post (members) and maybe a server addon kicks people that dont identify with the correct client

and you can only click on a thread and answer to a thread, never into the main muc

Does this mean there always ends up being an "offtopic" or "general" thread that's the new main muc?

(which is probably fine, just trying to nitpick things that feel odd)

there is no main muc

you have to add a thread to post

like on the mailing list

i mean you could create a general thread

which is probably the same as posting to the main muc

could we not even write a application on the server that transforms the stanzas and groups them via threads, for a webview

wonder that nobody did something like that already

lovetox: sounds like a web forum to me

yeah though via xmpp :D

Yeah, let's reinvent a bad clone of NNTP over XML

Forum + xmpp, would be really cool

SamWhited: Yeah! But it'll never come back.

😟

Indeed; when I was in school we had free usenet on the campus network; it was great. All the clubs and frats and what not got issued a git.sga.yourclub or something (not that anyone ever used it; the theater did a bit for whatever reason though); but sometime during my junior year the guy who had built the system in the 90's came back to work at the school, was suprised to still find it running, and shut it down. It was very sad.

We had a sat feed during the second half of the 90ies, it was awesome. Then the feed provider went bankrupt

The problem with usenet in a nutshell… everyone who tried to run the infrastructure decided to synchronize alt.binaries or whatever, and then went bankrupt :)

:D

SamWhited: that's because every user wanted alt.binaries ...

And nothing else

jonasw: any particular reason the ecaps2 example uses BombusMod?

:)

Flow: i think I even mention how I picked the examples

("first one in my capsdb which has this and that thing I want to show in that particular example")

jonasw: ok, I obviously didn't read that

I knew people would wonder that :-)

is BombosMod still acticely developed?

I have no idea.

I am open to choosing different examples if it matters.

no, was just wondering

I do like what I read in ecaps2 so far

that’s nice to hear :)

did you already get feedback from wasqas?

I don’t think so

should probably ping him directly

why not, I don't think he would mind

jonasw: Once this is accepted, you should add references to the RFCs for UTF-8 and base64

right, I’ll add it to my notes

using hashes:hash is also uncommen, but likely not invalid XMPP, but I wonder how many XMPP libs would break

right, quite a few

might adapt that example, even though it’s valid.

makes it shorter to read though

note also that in the wire format examples, I use xmlns="…" instead of prefixes

jonasw: also possible s/Append a "."./append a FULL STOP character (U+002E, ".")/, which would be how RFCs reference characters

that sounds better

noted

ooh, I didn't actually notice that. FWIW, I would have -1ed it if I did.

I obviously didn't read this carefully enough :)

SamWhited: which exactly?

Use of namespace prefixes

uh

what's wrong with namepsace prefixes?

didn’t know that it was such a red flag. it’s not even in a wire format example though.

Ah, yah, reading over this and it doesn't look like they're required, just part of the example so I don't care as much. But yah, I deeply hate them.

SamWhited: I don't think that you hate them is a valid reason to -1 a ProtoXEP

I like them. of course I don’t require them, because at the layer we’re working at, there’s nothing we can do to require them, really :-)

Nothing handles namespaces properly, and I constantly have to fight with the fact that stream's use prefixes and if you don't do it stuff breaks even if your stuff is technically still valid

s/Nothing/Nothing you use/

libxml and expat handle them just fine

We had the discussion to introduce a generic 'by' attribute using a prefix which gets re-used by other XEPs

Yah, fair; nothing I use. But as far as I can tell libxml2 and expat are just about the only things that handle them fine

And I still like the idea

frankly I don’t understand what’s so hard about handling XML namespaces in parsing or serialisation.

It's not "hard" there are just too many edge cases because there are so many ways to represent the same data

Which leads to bugs

At least, that was my take from briefly playing around with creating a namespace aware XML parser

But personally I think we shouldn't encourage the use of namespace prefixes, it will just lead to interoperability issues. Just keep it simple.

Personally I think we shouldn’t cater for broken XML implementations.

I agree in principle, but not in practice.

but I bow to reality

if i send a message out to my own bareJID, will i always get the message back at the sending resource? or could the server choose another resource?

Ge0rG,

lovetox, It's the same as any other message to your bare jid, and will be routed to one or more resources as per RFC 6121.

What have you people been up to today?

that is a bit vague

deliver the message to the "most available" resource or resources (according to the server's implementation-specific algorithm, e.g., treating the resource or resources with the highest presence priority as "most available")

thats my question, is the resource that sends the message out also the "most available" in that moment

so can i assume it will always get it back and not another resource

-xep best practices for resource locking

lovetox, Implementation-defined.

FWIW, we've had a long-standing stance to avoid namespaced attributes in the XMPP community.

On the basis that it's likely to break lots of things.

And that's about all I've got the energy to read up and notice.

Wait, namespaced *attributes*? I hadn't realised it was attributes. Nobody understands those (to a first approximation).

What's attributes?

Oh. It's not. It's just a prefixed element, albeit with the prefix defined in a containing element. That's fine, and I see nothign wrong in that.

It is? I thought someone said about namespaced attributes.

Assumign the "hashes:hash" comment is referring to the bit just above https://xmpp.org/extensions/inbox/ecaps2.html#usecases

I can't see anythign using namespaced attributes in there.

Also, I cannot type.

Ah, this is ecaps, not ISR?

I've just checked, they seem to be heavily used in ISR.

e.g. <enabled xmlns='urn:xmpp:sm:3' xmlns:isr='urn:xmpp:isr:0' isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52' isr:location='isr.example.org:5222'/>

lovetox:

Which is what I understand by the term 'namespaced attribute', at least.

You are totally

Oh, I've been staring at that recently and didn't notice them.

breaking my highlights.

Ge0rG, You should have them done at my place, that Julian he does my hair lovely.

lovetox: there is no guarantee that you will receive the Self-JID message, unless you send it to your own full JID. But you will probably receive the carbon, unless you are on m-link,which is now breaking expectations by doing the right thing

And this is why everything in XMPP is complicated.

thats the problem i found out just now

if the server doesnt sent it back to the sending resource

the resource that gets the message, gets also a "sent" carbon

so double message again

and this time i can only deduplicate if i go to the db and see if the stanza id is already there

lovetox: the best thing to do is to rely on 0198 acks and filter out the duplicate

lovetox: yes, unless you already got the same stanza id some time in the past

gajim uses uuid

My MUC code used to rely on unique stanza ids, it was a bad idea

lovetox: okay, if you only ever t check an ID generated by gajim, you'll be fine

but thats a lot of work to get self messaging to what i want it to be :/

lovetox: the good thing is that you are probably guaranteed to receive the message and the carbon right after each other.

yeah its actually not a problem right now, because gajim has a mechansim in which it caches a hash of various message attributes, and drops messages with the same hash

That sounds like somebody could exploit it

to what end?

lovetox: to prevent you from seeing messages?

you can only achieve the same hash when you write the same message

so i dont want to see that

lovetox: is it a cryptographic hash?

sha256

you would have to put in real effort to not let me see that message

you could also just not write it :D

ok have to go, good night :)