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/>).
moparisthebesthas joined
jerehas joined
Holgerhas left
jcbrandhas joined
Valerianhas left
Valerianhas joined
Martinhas left
Martinhas joined
moparisthebesthas left
jubalhhas joined
jubalhhas left
moparisthebesthas joined
vurpohas left
vurpohas joined
danielhas left
danielhas joined
danielhas left
danielhas joined
vurpohas left
nicolas.veritehas joined
nicolas.veritehas left
vurpohas joined
danielhas left
danielhas joined
danielhas left
danielhas joined
jcbrandhas left
jcbrandhas joined
Alexhas left
Alexhas joined
jcbrandhas left
jcbrandhas joined
dwd
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.
jonasw
not really
jonasw
just a stub
jonasw
well, we’re implementing XEP-84, but not <pointer/>, to make it clear
dwd
I'd be inclined to strip <pointer/>, even if it's Draft, to be honest. I can't see how it's interoperable.
jonasw
I find it a bit annoying that one can only save image/png in PEP there
jonasw
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 :(
Zash
Only when only one node is supported, like how some popular implementation(s?) do it.
jonasw
what do you mean?
dwd
Zash, No, I think the text as written restricts the <data/> element to be image/png only.
Zash
What
jonasw
yes
Zash
Where?
dwd
Zash, §4.1
Zash
-xep 84
jonasw
> 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.)
Bunneh
Zash: XEP-0084: User Avatar (Standards Track, Draft, 2016-07-09)
See: https://xmpp.org/extensions/xep-0084.html
kalkinhas left
Zash
Is that new?
jonasw
hopefully not. this is a MUST and the XEP has been in draft since 2008 or something :)
jonasw
2007 even
kalkinhas joined
dwd
Changed in 2007, just before Last Call.
dwd
Version 0.12. Or at least, that's when the line was edited.
Zash
I thought that it said "If only one item is published, it has to be PNG. Other items can be whatever."
bjchas left
dwd
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.
bjchas joined
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
Zash
But since in practice you are going to have a hard time publishing multiple items...
nicolas.veritehas left
Zash
The png-only text shows up in https://xmpp.org/extensions/attic/jep-0084-0.7.html#proto
jonasw
wait, if PEP won’t allow more than one item the XEP has a data race
winfriedhas left
Zash
Wasn't there a feature for that?
waqashas joined
Alexhas left
Flowhas joined
Steve Killehas left
nicolas.veritehas joined
nicolas.veritehas left
Steve Killehas left
jonasw
dwd: let’s keep <pointer/>
jonasw
it may be useful if we ever want to extend XEP-84.
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
Ge0rG
Would it be sensible to change Core routing / Carbons to only deliver the message to your _other_ clients?
Ge0rG
or is this something that should be handled in the client?
nyco
Ge0rG, marginal case, as I guess? or is there real use?
Tobias
Ge0rG, MAM should be the source of truth, not?
Ge0rG
nyco: I'm messaging myself all the time (URLs to my mobile etc), and I'm using a secondary JID because duplicates look bad
Ge0rG
Tobias: MAM will obviously also contain two copies
Ge0rG
Tobias: the incoming and the outgoing one
xnyhpshas joined
Tobias
Ge0rG, yeah?
nyco
so why not store those things in a private pubsub node?
Tobias
Ge0rG, maybe there could be a mention of it in MAM to allow server to optionally remove that one duplicate
Ge0rG
nyco: because every client supports messaging, and no clients support private pubsub nodes.
Ge0rG
Tobias: that's not so easy.
Ge0rG
Tobias: MAM is only if you come online later on. Carbons / core 6121 is when you are online
Ge0rG
Which is one of the reasons I'm insisting on making MAM-subscribe a thing.
intosi
Ge0rG: that's what M-Link does. Messages to self are archived just once.
intosi
And, as a result, returned just once.
Ge0rG
intosi: are carbons of messages-to-self also inhibited?
intosi
Carbons are not archived.
Ge0rG
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?
intosi
And messages to self follow the normal carbons rules. Only interested clients that aren't snders or recipients already will receive them,
Ge0rG
intosi: because a message-to-self is two messages in most cases :>
blipphas joined
Ge0rG
and from my reading of 6121+Carbons, you can't strip out one of them without violating the protocol
Alexhas joined
intosi
I'll probably regret asking immediately, but why?
nicolas.veritehas left
Ge0rG
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
uchas left
Ge0rG
intosi: and an outgoing message must be carboned to all other carbon-enabled resources
uchas joined
intosi
Yeah, sure. And you're claiming a server must do both sent and received handling separate?
Ge0rG
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
intosi
I chose not to do that, it's stupid.
Ge0rG
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
Steve Killehas left
fippo
tobias: video hangouts with a new interface. watch https://www.youtube.com/watch?v=8a-mmT9ifss if you're interested
Tobias
fippo, ta
intosi
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.
intosi
On which resources, apart from normal RFC routing, I mean.
Ge0rG
intosi: you are right of course. But even normal RFC routing is convoluted in this case.
intosi
Didn't touch RFC routing rules at all.
Ge0rG
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.
Ge0rG
Then the sending client will end up with two copied, and every other client with only 1.
intosi
Ge0rG: perhaps in your code base.
Steve Killehas left
Ge0rG
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
Ge0rG
there is no "you can ignore the sending JID of self-messages" exception
Ge0rG
I wish there were.
nicolas.veritehas joined
intosi
I'm probably too stupid to understand what your problem is.
lovetoxhas joined
Flow
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?
Ge0rG
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.
Ge0rG
Flow: no. I'm saying that, carbons-aside, you'll end up with partial message duplication based on 6121.
goffihas left
Ge0rG
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
nycohas left
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
Flow
Hmm, I think I don't have the whole picture of the problem. Maybe post to standards@?
Ge0rG
But then again, I also think that 6121 bare-JID routing rules are fundamentally broken for the IM use case.
Ah, now I understand you. Yes, foo/A sending to foo will result in a copy to self.
intosi
See, I'm too stupid to understand your words.
Ge0rG
intosi: I'm too stupid to find the right words to make the problem accessible
intosi
What will not happen, is sent carbons to be generated, even if you send to a bound JID foo/B.
Ge0rG
intosi: feel free to comment that you won't violate 6121, and that my claim of such is a blatant lie
intosi
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.
intosi
Anyway, sensible clients bind to a full jid as soon as they can anyway.
Ge0rG
intosi: resource-binding only adds to the uncertainity
Ge0rG
sensible clients should always send to bareJID because the server knows better which resources are there.
Ge0rG
the only exception is OTR, which is considered generally broken.
intosi
I disagree, except for the OTR bit.
dwd
Ge0rG, "always"?
Ge0rG
dwd: yeah.
dwd
https://xmpp.org/extensions/xep-0296.html
danielhas left
danielhas joined
jubalhhas joined
Ge0rG
dwd: following that XEP leads right into madness land.
Holger
It would be so nice if that idea worked out in practice ...
Ge0rG
dwd: just consider the race conditions between sending a message to a locked JID and that locked JID disappearing.
Ge0rG
Things are getting even funnier if you change client behavior based on the locked JID's supported features.
Lancehas joined
Ge0rG
You start typing a LMC correction, but then another client of your buddy comes online, you get unlocked and your client refuses to LMC.
Ge0rG
..or doesn't ask for a 0184 ack.
Ge0rG
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.
dwd
You seem to have got started on the thing you claim you don't want to get started on.
Ge0rG
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".
Guushas left
Ge0rG
dwd: no, I didn't. Carbons are a whole different can of worms.
Flow
Ge0rG: I believe any sensible client does already that
Ge0rG
Flow: does what?
moparisthebesthas left
Ge0rG
Flow: intosi> Anyway, sensible clients bind to a full jid as soon as they can anyway.
Flow
Ge0rG: But with carbons on both ends, where is the issue when performing resource locking?
Ge0rG
Flow: see above.
Ge0rG
Flow: also, if the receiving client goes offline, even with carbons, the server will generate error responses for the queued messages
Flow
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
sonnyhas joined
Ge0rGis an ignorant developer as well. Just doesn't care about CAPS and sends whatever features he wants to the bare JID
Ge0rG
because most of the features supported by yaxim fail safe, and because it doesn't support many features, it works out excellently.
Flow
CAPS?
Ge0rG
Flow: 0030/0115
jubalhhas left
sezuanhas left
danielhas left
danielhas joined
vurpohas left
danielhas left
vurpohas joined
danielhas joined
Guushas left
kaboomhas left
jcbrandhas left
sonnyhas joined
kalkinhas left
kalkinhas joined
jubalhhas joined
sonnyhas joined
jubalhhas left
Valerianhas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
jonaswhas left
vurpohas left
vurpohas joined
danielhas left
danielhas joined
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
archas left
archas joined
jonaswhas left
danielhas left
danielhas joined
ralphmhas left
danielhas left
danielhas joined
danielhas left
danielhas joined
danielhas left
danielhas joined
mimi89999has left
danielhas left
tim@boese-ban.dehas joined
danielhas joined
xnyhpshas left
danielhas left
danielhas joined
nycohas joined
danielhas left
danielhas joined
tim@boese-ban.dehas joined
nicolas.veritehas joined
lovetox
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
jonasw
lovetox: actually, those use cases are awesome. the problem is only that noone has ever found a good UI for them.
lovetox
they feel like "look what we could do if somebody would find some use case for this"
Ge0rG
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
nicolas.veritehas left
jonasw
+1 Ge0rG
jonasw
haven’t had a good idea yet, unfortunately
Ge0rG
I'm actually thinking about adding a thread-ID in yaxim when you tap on a nickname to do nickname completion
jonasw
not sure that’d perform well
Ge0rG
jonasw: it would probably cause gazillions of false-positives, but then again: no sane client relies on thread-ids to mean anything :P
lovetox
you mean in a muc
Ge0rG
lovetox: yeah
lovetox
so that you tap a button and start a new thread
lovetox
and how does the other client respond to the thread?
jonasw
with tapping I can actually imagine that this would work
Ge0rG
lovetox: no. you tap on a message to continue that thread
jcbrandhas joined
jonasw
I cannot imagine how that works in a desktop application
jonasw
as soon as you have multiple threads with overlapping participants :(
Ge0rG
jonasw: also tab completion :P
jonasw
Ge0rG: see above
jonasw
with yaxim you could use the thread of the message which the user tapped at for completion
lovetox
and then reorder messages so messages from threads are grouped?
jonasw
maybe
Ge0rG
maybe one could add colors to message threads
Ge0rG
as a subtle hint
jonasw
like this? https://wiki.xmpp.org/web/Contact_Colors
Ge0rG
anyway, I gotta run.
devnullhas left
Ge0rG
jonasw: yeah, nickname --> text color; thread --> bg color
Ge0rG
severe eye injury!
jonasw
ouch
lovetox
so for muc i feel this is not too hard to implement
lovetox
its just the ui how you respnd
lovetox
or switch thread
jonasw
yes, the UI is hard
jonasw
exactly
jonasw
unfortunately; because I think it could add a lot of it worked magically
Ge0rG
that would intuitively work for pseudo-forums, but not for IM
jonasw
wtf
lovetox
there needs to be a feature, that lets me add a name to the thread
jonasw
the wiki dropped my non-latin1-characters
jonasw
what the heck
danielhas left
lovetox
so then someone could hit a key and cycle the thread names
lovetox
and write to the one he wants
danielhas joined
Ge0rG
lovetox: why names? just use <Tab> to color-highlight the threads one by one.
lovetox
can we just add a name tag to the thread element
jcbrandhas left
Ge0rG
Or maybe... Meta-Tab, because Tab is already used for nick completion :P
lovetox
on desktop i have endless possibilities with shortcuts i dont see a problem with that
Valerianhas joined
Ge0rG
lovetox: yes, but your users don't have infinite memory for shortcuts
jonasw
right
lovetox
so the client automatically gives a color to a new thread
jonasw
this is IM, not blender
lovetox
this can get tricky in a muc with much threads
lovetox
names are better i think
jonasw
names requires extra user interaction
jonasw
-> won’t be used
Valerianhas left
Valerianhas joined
Ge0rG
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
jonasw
hm, interesting approach, too
lovetox
but to be honest, on a smartphone, a muc is cramped already
lovetox
on desktop this could be a really nice feature
lovetox
i mean you have space for 3 messages on a smartphone ^^
Ge0rG
I have enough space for five
lovetox
threads or not, you will not have a sense of overview in a muc on a smartphone
lovetox
especially not one where much goes on
jonasw
depends, if the threads are properly done and you view only those you are interested in…
jonasw
but I doubt that will work reliably, because users will accidentally post messages in the wrong thread
jonasw
interesting question: can LMC modify the <thread/>?
Ge0rG
yeah, collapsing / ignoring threads would be awesome on smartphones
goffihas left
Ge0rG
"The Sender MUST NOT include a correction for a message with non-messaging payloads." - looks to me like it's not forbidden
Ge0rG&
jonasw
fg
danielhas left
danielhas joined
SamWhitedhas left
nicolas.veritehas joined
nicolas.veritehas left
Steve Killehas left
Steve Killehas left
Ge0rG
What? Hey!
mhterreshas left
Steve Killehas joined
nicolas.veritehas joined
lovetox
yeah pretty nice idea for threads
nicolas.veritehas left
lovetox
but i see this more as a feature for serious work groups etc
lovetox
not for your everyday muc
jonasw
lovetox, indeed
lovetox
on desktop you could capture all threads put them into a list
lovetox
let the user name them
Ge0rG
If done right, it could work for both
lovetox
on click open a tab that displays only msgs from that thread
lovetox
that way i also know to which thread a user wants to respond
Ge0rG
But then, there will be the one client that fails, the Outlook of XMPP, the Pidgin of Carbons, where it's just plain broken
lovetox
i just treat it like a new conversation
nicolas.veritehas joined
nicolas.veritehas left
lovetox
yeah Ge0rG thats why i said its probably only for serious groups
lovetox
that know what they are doing
Ge0rG
lovetox: rule number 1 of interface design: users don't know what they are doing
jonasw
that
SamWhitedhas joined
Martinhas left
jerehas left
jerehas joined
lovetox
Ge0rG, on the topic of self messaging
lovetox
receipts have no use in my opinion
lovetox
on sent message if you dont get a error stanza from the server, you can see it as delivered
lovetox
it doesnt matter if your other client is online and sends a received stanza..
jonasw
right, stream management tells you that it has been processed by the server
nicolas.veritehas joined
lovetox
i dont know when i ever would need that info
lovetox
i mean if you client is not totally broken you will get that message via MAM or offline message or carbons or whatever
nicolas.veritehas left
jonasw
you’d want to be sure that you can find it in MAM later
jonasw
for this you need to make sure that the message actually makes it to the server
jonasw
-> SM
Ge0rG
lovetox: see, some client developers can't even send a coherent message with a highlight, how are Normal Users supposed to manage threads? 😀
lovetox
so i think i will deactivate receipts for self messaging, its only noise
Ge0rG
lovetox: sounds good enough to me.
lovetox
chatstates dito
Ge0rG
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.
jonasw
Ge0rG: SM should be a sufficient source for that, no?
lovetox
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
lovetox
at least in gajim that would be way easier then to do this via sm stanzas
Ge0rG
lovetox: no 'sent' receipt on outgoing message
Tobias
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
lovetox
Ge0rG, then the received ?
lovetox
that we want to get rid off ^^
Ge0rG
lovetox: Yeah, unless you're on mlink
fippo
tobias: well, meet. doesn't work in Firefox anymore than hangouts does...
lovetox
see now would be cool when we could join our own thread Ge0rG :D
Tobias
hangouts requires a plugin in FF anyway, not?
fippo
well, npapi died.
blipphas left
nicolas.veritehas joined
nicolas.veritehas left
Ge0rG
lovetox: Yeah. Good luck getting that UX sorted out and introduced into all Jabber.. No, XMPP clients.
lovetox
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 :)
jonasw
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
nycohas joined
lovetox
i described it above, i would gather the different threads and display them in a list
lovetox
when the user clicks that list, a window opens where the messages are filtered with the thread
Ge0rG
This might also not be the biggest problem that gajim has...
lovetox
if he writes into that window, message goes to the thread
lovetox
seems pretty easy
blipphas joined
bithas left
lovetox
on desktop i dont have to put everything into one window :)
jonasw
yes you have.
jonasw
(but that is just my humble opinion ;-))
lovetox
dont limit the desktop to a bigger smartphone :)
jonasw
don’t litter my desktop with windows
lovetox
i actually dont, i can also use tabs inside one window ^^
SamWhited
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.
lovetox
yeah SamWhited of course you can sabotage it .. but if only gajim clients talk with each other it would work good :)
lovetox
and maybe others adopt it
lovetox
:)
jonasw
that’s not sabotaging, that’s simply interoperating
SamWhited
I read that as "so it will never work"
jonasw
or rather not interoperating
SamWhited
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.
lovetox
but the breaking has nothing to do with your UX
lovetox
it has to do with other clients
Ge0rG
You just add a context menu "join with thread" that opens a sub menu with a list of all threads
jonasw
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.
SamWhited
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"
jonasw
indeed
nicolas.veritehas joined
lovetox
somebody has to start
nicolas.veritehas left
jonasw
yes, it’s tricky
jonasw
it would be good if one could somehow sanely detect these clients and fall back to a sane non-threaded UI for those
jonasw
or rather if those clients participate
Ge0rG
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.
SamWhited
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)
lovetox
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 ..
lovetox
its just a addtional tab when you want to use it and it works
jonasw
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
SamWhited
Also between the same room on one day and the same room 10 minutes later
jonasw
ugh
jonasw
it’s all a mess.
SamWhited
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
jonasw
on a related matter: a XEP which allows me to post a simple reaction to a post would be great
jonasw
I’ve seen that with slack I think. or like you can on github issues
jonasw
those wouldn’t trigger any UI notifications, and it saves vertical space
Lance
https://xmpp.org/extensions/xep-0367.html ?
lovetox
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
SamWhited
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
jonasw
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)"
jonasw
ah cool, SamWhited
jonasw
I was already thinking about 367, but it seemed to be too broad for that. if it is intended to serve that purpose, great!
SamWhited
lovetox: But now when that user replies, your threads break and we're back to the beginning
Ge0rG
Somehow, my smartphone miscompleted roster into rosette...
waqashas left
lovetox
why would it break? what does breaking mean for you?
lovetox
adding a message that doesnt belong to the thread is breaking?
jonasw
lovetox: not correctly showing semantically related messages all the time
jonasw
yes.
jonasw
that’s breaking.
SamWhited
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
Lance
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
SamWhited
now the thread is split between two places
lovetox
so when i go to a message board and post in the wrong topic, i broke the topic?
SamWhited
Lance: ah yah, good point; we never actually got that far
lovetox
yeah that people answer to it with the wrong thread on the message, ok
lovetox
that is a problem in the start
lovetox
that the filtering is not good
lovetox
but it would get better and better as more clients adapt
lovetox
this does not even mean implementing the same thing
lovetox
just use some sane rules on threads
SamWhited
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.
Ge0rG
lovetox: in 20 years, there will still be people on the xsf MIX using Pidgin.
nycohas joined
lovetox
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
lovetox
and we ban the rest from all mucs :D
Lancehas left
Ge0rG
lovetox: on mobile, people will just tap on the first instance of the person they want to complete.
Ge0rG
And you really really really don't want to promote lightweight threads to windows
kaboomhas left
SamWhited
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
Ge0rG
SamWhited: sounds like slack
lovetox
UI for naming the threads then use tab completion
SamWhited
I haven't actually tried Slack since they introduced threading
SamWhited
lovetox: It's still more work than just typing your message and hitting enter, which means most people will ignore it
Ge0rG
SamWhited: I was the only one to try threading, so I consider it a UX failure
lovetox
not everything has to be used by everyone
SamWhited
Ge0rG: Yah, that's how I was with this messenger (I forget what it's called) that our team was playing with
SamWhited
lovetox: it does in this case, otherwise the threading is always broken and worthless
SamWhited
everyone or at least most people
Ge0rG
lovetox: you would need to provide visual hints, like color codes for the U to work out
SamWhited
That's what this did, which was actually rather nice, let me ask what it was called…
lovetox
ok what about this
lovetox
a work feature: there is no main chat view
lovetox
only a add thread button
lovetox
every thread gets his own window
lovetox
you can only answer to threads
SamWhited
Isn't taht just making new mucs at that point? (also, that still requires every client to do it)
lovetox
when you join you load mam, and get automatically a list with all threads
Ge0rG
lovetox: Yeah, will be broken immediately by an incompatible client
lovetox
thats why i said its a work feature
lovetox
like a company if they all use the same client
Ge0rG
And then some client will use auto increment integers for threads ids
lovetox
making a new muc has considerable overhead
SamWhited
yah, fair enough, it can work in closed environments
lovetox
actually is that not exactly what we need for mailing list replacement ^^
lovetox
a search function added and its perfect
lovetox
and its all archived in one single muc :D
Ge0rG
"Sending of MUC messages without a thread ID is disallowed by group policy. Please contact your chat administrator."
nycohas joined
Ge0rG
lovetox: and you only can get the last 50 messages.
SamWhited
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/
danielhas left
SamWhited
It was pretty nice looking, but when we tried it no one used threads, so I felt like it was a failure.
SamWhited
Or rather, one person did, and everyone else replied in the normal chat and then they didn't see replies in the thread
Ge0rG
SamWhited: maybe they were using the xmpp transport? 😀
danielhas left
uchas left
Tobiashas joined
uchas joined
uchas left
uchas joined
Tobiashas left
danielhas left
lovetox
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
jubalhhas joined
lovetox
and you can only click on a thread and answer to a thread, never into the main muc
SamWhited
Does this mean there always ends up being an "offtopic" or "general" thread that's the new main muc?
SamWhited
(which is probably fine, just trying to nitpick things that feel odd)
lovetox
there is no main muc
lovetox
you have to add a thread to post
lovetox
like on the mailing list
lovetox
i mean you could create a general thread
lovetox
which is probably the same as posting to the main muc
efrithas joined
danielhas left
lovetox
could we not even write a application on the server that transforms the stanzas and groups them via threads, for a webview
uchas left
danielhas left
uchas joined
lovetox
wonder that nobody did something like that already
uchas left
uchas joined
danielhas left
Ge0rG
lovetox: sounds like a web forum to me
lovetox
yeah though via xmpp :D
Ge0rG
Yeah, let's reinvent a bad clone of NNTP over XML
SamWhitedwishes he could just have his usenet back and be done with it.
uchas left
SouL
Forum + xmpp, would be really cool
uchas joined
danielhas left
Ge0rG
SamWhited: Yeah! But it'll never come back.
Ge0rG
😟
SamWhited
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.
Ge0rG
We had a sat feed during the second half of the 90ies, it was awesome. Then the feed provider went bankrupt
nicolas.veritehas joined
nicolas.veritehas left
SamWhited
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 :)
danielhas left
jonasw
:D
Ge0rG
SamWhited: that's because every user wanted alt.binaries ...
Ge0rG
And nothing else
danielhas left
danielhas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
danielhas left
nicolas.veritehas joined
nicolas.veritehas left
archas left
archas joined
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
nycohas left
jubalhhas left
jerehas left
goffihas joined
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
Tobiashas left
danielhas left
nicolas.veritehas joined
nicolas.veritehas left
jerehas joined
danielhas left
danielhas left
uchas left
danielhas left
Alexhas left
Alexhas joined
danielhas left
danielhas left
Flow
jonasw: any particular reason the ecaps2 example uses BombusMod?
Flow
:)
jonasw
Flow: i think I even mention how I picked the examples
jonasw
("first one in my capsdb which has this and that thing I want to show in that particular example")
Flow
jonasw: ok, I obviously didn't read that
jonasw
I knew people would wonder that :-)
Flow
is BombosMod still acticely developed?
jonasw
I have no idea.
jonasw
I am open to choosing different examples if it matters.
Flow
no, was just wondering
Flow
I do like what I read in ecaps2 so far
jonasw
that’s nice to hear :)
danielhas left
Flow
did you already get feedback from wasqas?
jonasw
I don’t think so
jonasw
should probably ping him directly
Flow
why not, I don't think he would mind
Flow
jonasw: Once this is accepted, you should add references to the RFCs for UTF-8 and base64
jonasw
right, I’ll add it to my notes
Flow
using hashes:hash is also uncommen, but likely not invalid XMPP, but I wonder how many XMPP libs would break
jonasw
right, quite a few
jonasw
might adapt that example, even though it’s valid.
jonasw
makes it shorter to read though
jonasw
note also that in the wire format examples, I use xmlns="…" instead of prefixes
nycohas joined
Flow
jonasw: also possible s/Append a "."./append a FULL STOP character (U+002E, ".")/, which would be how RFCs reference characters
jonasw
that sounds better
jonasw
noted
SamWhited
ooh, I didn't actually notice that. FWIW, I would have -1ed it if I did.
SamWhited
I obviously didn't read this carefully enough :)
jonasw
SamWhited: which exactly?
SamWhited
Use of namespace prefixes
jonasw
uh
Flow
what's wrong with namepsace prefixes?
jonasw
didn’t know that it was such a red flag. it’s not even in a wire format example though.
SamWhited
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.
Flow
SamWhited: I don't think that you hate them is a valid reason to -1 a ProtoXEP
jonasw
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 :-)
SamWhited
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
jonasw
s/Nothing/Nothing you use/
jonasw
libxml and expat handle them just fine
Flow
We had the discussion to introduce a generic 'by' attribute using a prefix which gets re-used by other XEPs
SamWhited
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
Flow
And I still like the idea
jonasw
frankly I don’t understand what’s so hard about handling XML namespaces in parsing or serialisation.
SamWhited
It's not "hard" there are just too many edge cases because there are so many ways to represent the same data
SamWhited
Which leads to bugs
SamWhited
At least, that was my take from briefly playing around with creating a namespace aware XML parser
waqashas joined
SamWhited
But personally I think we shouldn't encourage the use of namespace prefixes, it will just lead to interoperability issues. Just keep it simple.
jonasw
Personally I think we shouldn’t cater for broken XML implementations.
SamWhited
I agree in principle, but not in practice.
jonasw
but I bow to reality
Guushas left
nycohas joined
nycohas joined
lovetoxhas left
lovetoxhas joined
danielhas left
nycohas joined
pep.has joined
Guushas left
danielhas left
waqashas left
waqashas joined
Guushas left
Guushas left
jonaswhas left
danielhas left
lovetox
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?
lovetox
Ge0rG,
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
dwd
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.
nicolas.veritehas joined
nicolas.veritehas left
moparisthebesthas joined
Zash
What have you people been up to today?
goffihas left
kaboomhas left
lovetox
that is a bit vague
lovetox
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")
lovetox
thats my question, is the resource that sends the message out also the "most available" in that moment
lovetox
so can i assume it will always get it back and not another resource
Zash
-xep best practices for resource locking
danielhas left
dwd
lovetox, Implementation-defined.
winfriedhas left
danielhas left
nicolas.veritehas joined
nicolas.veritehas left
Alexhas left
SamWhitedhas left
nycohas joined
kaboomhas left
Alexhas joined
intosihas left
Tobiashas left
bearhas left
suzyohas joined
bearhas joined
Kev
FWIW, we've had a long-standing stance to avoid namespaced attributes in the XMPP community.
Kev
On the basis that it's likely to break lots of things.
Kev
And that's about all I've got the energy to read up and notice.
dwd
Wait, namespaced *attributes*? I hadn't realised it was attributes. Nobody understands those (to a first approximation).
Flowhas joined
goffihas joined
Flowhas left
Zash
What's attributes?
Lancehas joined
dwd
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.
Kev
It is? I thought someone said about namespaced attributes.
dwd
Assumign the "hashes:hash" comment is referring to the bit just above https://xmpp.org/extensions/inbox/ecaps2.html#usecases
dwd
I can't see anythign using namespaced attributes in there.
dwd
Also, I cannot type.
Kev
Ah, this is ecaps, not ISR?
Kev
I've just checked, they seem to be heavily used in ISR.
Kev
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'/>
Ge0rG
lovetox:
Kev
Which is what I understand by the term 'namespaced attribute', at least.
Ge0rG
You are totally
dwd
Oh, I've been staring at that recently and didn't notice them.
Ge0rG
breaking my highlights.
dwd
Ge0rG, You should have them done at my place, that Julian he does my hair lovely.
Ge0rG
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
Ge0rG
And this is why everything in XMPP is complicated.
lovetox
thats the problem i found out just now
lovetox
if the server doesnt sent it back to the sending resource
lovetox
the resource that gets the message, gets also a "sent" carbon
lovetox
so double message again
lovetox
and this time i can only deduplicate if i go to the db and see if the stanza id is already there
Ge0rG
lovetox: the best thing to do is to rely on 0198 acks and filter out the duplicate
Ge0rG
lovetox: yes, unless you already got the same stanza id some time in the past
lovetox
gajim uses uuid
Ge0rG
My MUC code used to rely on unique stanza ids, it was a bad idea
Ge0rG
lovetox: okay, if you only ever t check an ID generated by gajim, you'll be fine
lovetox
but thats a lot of work to get self messaging to what i want it to be :/
Ge0rG
lovetox: the good thing is that you are probably guaranteed to receive the message and the carbon right after each other.
lovetox
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
Ge0rG
That sounds like somebody could exploit it
lovetox
to what end?
Ge0rG
lovetox: to prevent you from seeing messages?
lovetox
you can only achieve the same hash when you write the same message
lovetox
so i dont want to see that
Valerianhas left
Ge0rG
lovetox: is it a cryptographic hash?
lovetox
sha256
lovetox
you would have to put in real effort to not let me see that message