moparisthebest, I’m pretty sure that that’s not true. if only on the grounds that small parts would lack the Schöpfungshöhe (that’s the german term, sorry I don’t know the proper english one) to even be copyrightable.
jonasw
like, some constants which are irrelevant to the working of the protocol and are merely there to establish compatbility
waqashas left
ThibGhas joined
ThibGhas left
ThibGhas joined
tahas left
Valerianhas joined
Guushas left
ralphmhas left
Guushas left
Guushas left
Valerianhas left
Valerianhas joined
Guushas left
Guushas left
Guushas left
tim@boese-ban.dehas joined
Guushas left
ralphmhas joined
nycohas left
ludohas left
ludohas joined
ThibGhas joined
ThibGhas joined
j.rhas joined
davidhas left
davidhas joined
moparisthebesthas joined
Dave Cridlandhas left
Dave Cridlandhas left
Guushas left
Dave Cridlandhas left
tahas joined
Dave Cridlandhas left
Zashhas joined
j.rhas joined
Dave Cridlandhas left
Zash
jonasw: The being-enough-work-ines?
jonasw
Zash, yeah, kinda
jonasw
like, I could probably not claim copyright on a poem like:
Foo, the bar, frobnitzed the dingus.
jonasw
for certain definitions of poem
jonasw
then again, that might be dadaistic enough to work, but whatevre.
Dave Cridlandhas left
Zash
"Verkshöjd"
danielhas left
jonasw
is that a composed word of some kind? I get "verk", but I can’t interpret "shöjd"
I believe that the idea to distribute the persistent groupchat archives over multiple servers by having the participant's server also hosting a copy of the channel archive is a desirable.
But Georg got me thinking. It would be great if the participant's service could re-use the stanza-id's from the MIX channel in it's own archive for the user. That would be a great advantage in multiple aspects. We could possibly achieve this by moving the participant's copy of the MIX channel archive into a PEP node with the channel's JID as node name. Thoughts?
flow
I believe that the idea to distribute the persistent groupchat archives over multiple servers by having the participant's server also hosting a copy of the channel archive is desirable.
But Georg got me thinking. It would be great if the participant's service could re-use the stanza-id's from the MIX channel in it's own archive for the user. That would be a great advantage in multiple aspects. We could possibly achieve this by moving the participant's copy of the MIX channel archive into a PEP node with the channel's JID as node name. Thoughts?
Valerianhas left
flowfailed using poezio's LMC…
Yagizahas left
jonasw
what
jonasw
what would the advantages be?
j.rhas joined
Ge0rG
everybody would see which MUCs you are in!
j.rhas joined
moparisthebesthas joined
blablahas left
Yagizahas joined
intosihas left
intosihas joined
intosi has left
Valerianhas joined
mimi89999has joined
j.rhas joined
danielhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
j.rhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Tobiashas joined
danielhas left
jerehas joined
tahas joined
tahas joined
intosihas left
intosihas joined
jerehas left
jerehas joined
LNJhas left
LNJhas joined
j.rhas joined
Guushas left
Guushas left
Valerianhas left
Valerianhas joined
Valerianhas left
danielhas left
alexishas joined
alexishas left
ludohas left
ludohas joined
Dave Cridlandhas left
alexishas joined
SamWhitedhas joined
SamWhitedhas joined
Guushas left
ludohas left
ludohas joined
alexishas left
alexishas joined
Ge0rGhas left
Guushas left
Syndacehas joined
moparisthebesthas joined
Syndacehas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Valerianhas joined
efrithas joined
alexishas left
Syndace
There we go!
I'm exited to announce the release of my python-omemo implementation, which can be found on https://github.com/Syndace/python-omemo!
I'll try to be in the jdev@ and xsf@ mucs as much as possible to answer questions and fix bugs in the next weeks and I really hope this release will help OMEMO to improve.
alexishas joined
MattJ
Syndace, great news :) You should send an [ANN] to the jdev mailing list as well, for the client developers who are not in the MUCs
MattJ
(if you haven't already)
rion
Syndace: does gajim use it already?
Guushas left
LNJhas left
Syndace
rion: no, it was private until five minutes ago ^^
alexishas left
rion
=)
Zash
For each client written in python, ask "Does {client} use it already?"
alexishas joined
rion
One day I'll make a plugin for Psi to load python extensions =)
Kev
I did that with the original plugin implementation about 13 years ago, I think :)
rion
and javascript
Zash
Better avoid Lua tho, wouldn't wanna touch a language specifically designed for embedding. :)
ludohas left
ludohas joined
MattJ
Save that for writing servers
Zashhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
alexishas left
alexishas joined
marmistrzhas left
j.rhas joined
ralphm
Kev: I might have missed it, but is there a writeup for the so-called "xmpp2 routing" stuff discussed at FOSDEM?
ralphm
(or really, the Summit)
Ge0rG
ralphm: https://wiki.xmpp.org/web/XMPP_2.0 is probably the best resource, but pre-summit
Ge0rG
ralphm: also https://op-co.de/tmp/whats-wrong-with-xmpp-2017.pdf
Kev
ralphm: I think JC sent out minutes from the summit.
Thanks. It seems that the examples in the XMPP_2.0 wiki page are more fleshed out, but maybe we should have an actual XEP on this. I hear this being talked about a lot, but now having people implementing it (here) this is still a bit vague.
Andrew Nenakhovhas joined
intosihas left
intosihas joined
LNJhas joined
j.rhas joined
MattJ
ralphm, who is implementing it? I think it's a bit too early and vague for that...
MattJ
It has multiple unresolved issues
MattJ
"xmpp 2.0" is more a direction than a protocol
alexishas left
alexishas joined
Zash
The direction started by Carbons and MAM, prompted by mobile clients and "all messages on all devices" thing?
MattJ
Zash, I guess. But regardless of that, I don't think there is any denying that the proposed changes simplify a lot of things
ralphm
MattJ: my own team
ralphm
MattJ: and I'm talking about MIX, not XMPP 2.0.
ralphm
MattJ: however, part of MIX in its current form is a dependency on things handled by the participant's local server (roster integration, PAM).
marmistrzhas left
LNJhas left
ralphm
I'm also unsure how it works if a client only wants to receive notifications for a subset of the pubsub nodes subscribed to by the bare JID when joining the room.
flow
Syndace, +1
lskdjfhas joined
alexishas left
alexishas joined
j.rhas joined
ralphm
Or is that not a usecase that is covered by MIX?
moparisthebesthas joined
alexishas left
alexishas joined
Zash
Pretty sure that was part of the whole MIX design. Possibly handled by the pubsub-account stuff?
ralphm
Well, I can see that you can specify which pubsub nodes you want to subscribe to when joining a channel, I don't see how you can differentiate between different resources.
ralphm
(or whether this is actually a desirable feature)
Kev
ralphm: I can write up a 'new IM routing rules' XEP, at least an early version, it's on my TODO (along with quite a depressing amount of spec work, actually).
ralphm
Kev: cool. Does it correspond with that wiki page that Ge0rG linked, or is it different from that?
Kev
As for selective filtering of pubsub notifications I think that's a thing that is outside MIX or routing-NG.
Zash
Daves PAM?
Kev
I'm using "XMPP 2" to talk about how all these moving parts fit together sensibly, FWIW. It's too easy to change one bit in isolation and end up with a patchwork that doesn't do what's needed (see interactions between Carbons and MAM, for example).
ralphm
Kev: ok, but I'm still curious how it works, because now you're subscribed with the bare JID, you can't use CAPS filtering
ralphm: I mean that PAM is going to do filtering on the recipient side, when some clients aren't interested in some stuff to which a different client subscribed.
Kev
I think this actually goes far beyond pubsub, though.
ralphm
But I thought you said that with XMPP 2 routing you wouldn't need PAM?
Kev
You don't need some aspects of PAM, yea, but you still need something somewhere doing something.
Kev
Take the example people keep giving of not wanting a 5000-user MUC sending messages to your phone unless you're actively viewing it at the moment.
Kev
Which goes beyond selective filtering of pubsub notifications.
Kev
But does tie into the push and highlighting rules.
alexishas left
Kev
I did put some thoughts into https://github.com/Kev/xeps/blob/58153226d6caf93fbb2b4d3fbd9819e814942e37/inbox/multi-client.xml before the Summit, with the aim of getting it published as a rough overview of how everything comes together in xmpp 2.
Kev
Perhaps I should tidy it up a bit and get it submitted so we can have something outside the wiki.
alexishas joined
danielhas left
LNJhas joined
marmistrzhas joined
alexishas left
alexishas joined
efrithas left
danielhas left
lumihas joined
jerehas joined
Zashhas left
jerehas joined
marmistrzhas joined
intosihas left
intosihas joined
efrithas joined
j.rhas joined
LNJhas left
Guushas left
Guushas left
moparisthebesthas joined
alexishas left
alexishas joined
alexishas left
vanitasvitaehas left
alexishas joined
Guushas left
Guushas left
Guushas left
Zashhas left
Zashhas left
Zashhas joined
Syndacehas joined
mimi89999has joined
Guushas left
j.rhas joined
alexishas left
alexishas joined
danielhas left
ralphm
That'd be great
alexishas left
marmistrzhas joined
alexishas joined
danielhas left
SamWhitedhas joined
SamWhitedhas joined
alexishas left
alexishas joined
j.rhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
alexishas left
alexishas joined
jjrhhas left
Kev
I'm going to make activation of IM-NG an iq after bind, on the basis that it can then be wrapped up inside bind2.
ralphm
interesting
Ge0rG
how do you wrap an IQ into bind2?
Kev
Ge0rG: TBD.
Kev
But in principle by saying "also activate these things please".
alexishas left
Ge0rG
I'm not quite convinced.
alexishas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
waqashas joined
waqashas left
alexishas left
alexishas joined
waqashas joined
ludohas left
ludohas joined
alexishas left
alexishas joined
jjrhhas left
jjrhhas left
jjrhhas left
Yagizahas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
alexishas left
alexishas joined
jjrhhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
j.rhas joined
j.rhas joined
MattJ
daniel, is it the case that if an oob payload is in a message, Conversations only shows the attachment if <body> == URL?
Guushas left
danielhas left
alexishas left
daniel
Either body == oob
alexishas joined
daniel
Or just oob set and no body
tahas joined
MattJ
Does it use <desc>?
daniel
The first one is the one I usually expect. The later is only a bonus if you will
daniel
No
daniel
i can make it use desc on the sending side if you want me to
MattJ
Trying to figure out how I can send an image with a piece of text that works in clients whether they support oob or not
marchas joined
MattJ
e.g. I could do: <body>[some description]: [some url]</body> along with the oob payload
MattJ
But then Conversations wouldn't handle it the "nice way" (and I have no idea about other clients)
moparisthebest
what if you just send the image, followed by the description, in 2 different messages?
MattJ
as you raised on the mailing list, I think this is partly an issue with XEP-0066 being used differently to how it was originally intended, so the XEP doesn't help clarify things
jubalhhas left
Guushas left
Zash
moparisthebest: you could, but it'd be ... not nice.
Andrew Nenakhovhas joined
MattJ
moparisthebest, not ideal, but I considered it
MattJ
it's really more supposed to be like a caption for the image/file
MattJ
or a title, or something
MattJ
Imagine I sent multiple in a row. It wouldn't be clear if the text applied to the one above or the one below
moparisthebest
might just be the only thing that works well across everything *today*, come up with something better for the future :)
Zash
`body := url \n desc` would have been nice
daniel
don‘t let that stop you from coming up with something 'nice' but don’t expect Conversations to handle image and text in the same message any time soon
MattJ
daniel, is that just because of UI limitations?
daniel
the internal db is way too messed up for that
MattJ
Ok
daniel
and UI
daniel
but that's more 'solveable' than the db
moparisthebest
MattJ, yea I hit that problem with websites all the time, I'd think people would be used to it (if the first thing is an image, then description follows, if first thing is a description, then image follows)
alexishas left
alexishas joined
Guushas left
Guushas left
SamWhitedhas left
vanitasvitaehas left
jjrhhas left
MattJ
moparisthebest, except in an IM conversation, the first thing will generally always be text :)
MattJ
Maybe we should specify a new XEP for <hr> over XMPP
except Conversations won't show the image even though it could
alexishas left
MattJ
Can we just pick one?
alexishas joined
daniel
I'll probably support Sims at some point
jjrhhas left
MattJ
5
daniel
Or references. What ever the best practices will be
daniel
I thought Sims = references
Kev
Kinda.
Kev
Sims binds a transfer mechanism on top of references.
Kev
So it's a Reference with additional information on how to start a file transfer to get it.
Ge0rG
I thought Sims binds a green crystal on top of avatar heads.
Kev
I think we need to move towards References so we can do things like @mentions and the like sensibly.
Zash
-xkcd 927
Bunneh
https://imgs.xkcd.com/comics/standards.png
Standards
daniel
Kev: how would you attach an image with a reference w/o using Sims?
Ge0rG
daniel: http upload URI?
Kev
Define 'attach'.
Ge0rG
Kev: what about E2EE?
MattJ
Kev, so to get Swift to do what I want, I should follow XEP-372 or XEP-0385?
Kev
It's a reference to a URI, so you provide the image somehow (e.g. HTTP Upload) and then reference it.
daniel
I thought that's what Sims was
daniel
Only more specific to media
daniel
Whereas references are generic
Kev
MattJ: What exactly was it you wanted?
Kev
daniel: References are fairly generic, and Sims uses References.
peterhas joined
alexishas left
MattJ
Send an image with attached text, or text with attached image, whichever way you want to view it
alexishas joined
MattJ
oob url + desc does what I want already, except it's lacking client support
Kev
The image also needs to be transferred? Or that exists already?
MattJ
I have a URL for it
SamWhitedhas left
Kev
372 it.
SamWhitedhas joined
Kev
I expect this to be on trunk in the next couple of days in an early state (receiving, anyway, how to do this sending sensibly is a much harder question).
MattJ
372 feels strange for image attachment
MattJ
Looks like it wants a character range
MattJ
Which in my case is easily done - the entire message
jonasw
whereas "character" is not properly defined.
MattJ
But if I only set the range to half the message, what would it show?
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Kev
In the case of image URIs, Swift's not going to do much of anything with the range, and you could elide either the range or the URI in the body ok.
Ge0rG
Also should it hide the referenced text? use it as an alt tag?
Ge0rG
We need to have the URI in the body for legacy clients.
Kev
It's more interesting when you've got something like @MattJ and you want to link that to the appropriate user in the UI.
MattJ
Sure, I understand it for that use-case
MattJ
For my current one however, it feels wrong
Kev
Just don't include a range :)
jonasw
I’d also like to have a range-less thing which uses SIMS syntax. kinda like OOB with more metadata.
jonasw
but how to handle cases when there /is/ a range
MattJ
Oh wait, it's optional, ok
alexishas left
alexishas joined
alexishas left
Tobias
MattJ, what do you think about 385? But that probably shares similar problems as references. At least on the outer level.
efrithas left
alexishas joined
alexishas left
MattJ
I don't know yet
Kev
https://github.com/xsf/xeps/pull/614 - very basic outline of XMPP 2 IM routing.
Kev
ralphm: ^
lovetoxhas joined
Tobias
daniel, but yeah, SIMS is basically references + metadata + source hints on how to get the data
Ge0rG
Kev: just in time for Council meeting?
Kev
And as we're putting metadata into 372 imminently, I guess 385 will move to be References source hints.✎
Tobias
daniel, but i think there are plans to shove metadata into references
Kev
And as we're putting metadata into 372 imminently, I guess 385 will move to be References + source hints. ✏
alexishas joined
Tobias
Kev, nah..you can shove the source hints into references too
marchas left
Tobias
Kev, i guess you could also force a thumbnail into references somehow ;)
alexishas left
MattJ
I've not been following any of these XEPs, and I suddenly feel how it must feel to non-XMPP folk trying to get stuff done
alexishas joined
daniel
yeah i'll let you people figure that stuff out and then just implement what ever the best practices turn out to be
Kev
MattJ: That's actually why I think a meta-XMPP2 XEP like https://github.com/Kev/xeps/blob/58153226d6caf93fbb2b4d3fbd9819e814942e37/inbox/multi-client.xml is going to be important.
Tobias
daniel, sensible :)
Kev
Or the Compliance Suites remastered as just Current XMPP Version
SamWhited
That's an interesting idea
alexishas left
Zash
Hm?
SamWhited
I like it; though I'd be even more worried about us never releasing them and them ending up in a state where no one is really working on them.
Zash
Separation of "This is what's implemented today" and "This is what we want the future to be like" ?
SamWhited
I don't think it has to be imlemented today, it can also be "this is what the next version of XMPP looks like, now go implement it" as long as the specs exist.
Zash
Hm?
ludohas joined
Yagizahas joined
Zash
A document describing "Currently, implementations are doing this and that."
Zash
And, in a separate document, something of a vision statement.
Dave Cridlandhas left
Kev
I think what Zash says has considerable value.
remkohas joined
Kev
Or something along those lines.
lovetoxhas left
MattJ
+1
alexishas joined
Dave Cridlandhas left
tuxhas joined
Dave Cridland
I think the two are needed - ie, "this is what is done now", and "this is where we'd like to be".
tuxhas left
Kev
I wouldn't 'this is where we'd like it to be' as much as 'this is what we expect the next version of Done Now to be', but something along those lines.
Dave Cridlandhas left
Zash
In various non-profits I've been involved in, at the member meetings, there's usually one point of order for a report what the org has done since the last meeting, and a point about what the org is to do for the next period.
Zash
So, something corresponding to that is what I'm thinking.
la|r|mahas left
Zash
Tho I can see how this could be three things
Dave Cridlandhas left
Zash
1) State of XMPP today
2) Expected of XMPP tomorrow (short term, in-progress things)
3) Long term vision (what we want XMPP to be in some magical future)
ralphmhas joined
Kev
I don't see a reason 2/3 can't be a single XEP, but I'd be kinda keen on (1) being one of its own.
lovetoxhas joined
alexishas joined
jerehas joined
Zash
Kev: Sure. I suppose one could differentiate between 2 vs 3 into "things doable this term" and "things after this term" (roughtly council/board terms)
tahas joined
Zash
Having snapshots of how the state of things were in the past would be nice to have in the future.
Kev, Have you been using my trick of declaring the namespace in an entity to make bumping it easier? :-)
jonasw
does that even work with CDATA?
davidhas joined
Dave Cridland
jonasw, No, nothing at all works inside CDATA, so i have to terminate the CDATA section, do the entity, and reopen.
moparisthebest
Maranda, it doesn't say it supports OMEMO, it says it "Advertises OMEMO Support" :P
Dave Cridland
jonasw, Saves me remembering what I chose for the namespaces, though.
jonasw
Dave Cridland, ah that makes sense
davidhas joined
Guushas left
alexishas left
Dave Cridlandhas left
alexishas joined
Maranda
moparisthebest, JSXC supports OMEMO *I think*
Maranda
moparisthebest, else it doesn't make sense
moparisthebest
it didn't last time I saw it but that sounds good
LNJhas joined
jjrhhas left
jjrhhas left
jjrhhas left
Guushas left
peterhas left
jjrhhas left
jjrhhas left
jjrhhas left
jerehas joined
jubalhhas joined
alexishas left
jubalhhas left
alexishas joined
jjrhhas left
jjrhhas left
jjrhhas left
marmistrzhas joined
Dave Cridlandhas left
alexishas left
alexishas joined
la|r|mahas left
Dave Cridlandhas left
Maranda
moparisthebest, the funny thing is that they "added" all these features but still manage to not get how to output rfc compliant JSON.
SamWhitedhas left
SamWhitedhas joined
Dave Cridlandhas left
SamWhitedhas joined
Neustradamushas left
davidhas left
davidhas joined
alexishas left
alexishas joined
marmistrzhas joined
Dave Cridlandhas left
alexishas left
alexishas joined
LNJhas left
Dave Cridlandhas left
alexishas left
Marandahas joined
alexishas joined
jonasw
Syndace, regarding the magic values from the signal code, if we ever define our own ones/our own wire format, we won’t be compatible with the libsingal clients anymore, will we?
Steve Killehas left
Zash
Doomed!
Dave Cridlandhas left
Syndace
jonasw, yeah, that's the reason why I copied these magic values in the first place - to be compatible to the current libsignal clients.
Steve Killehas left
Zash
Are magic numbers copyrightable?
daniel
Are you asking oracle that question?
jonasw
:(
SaltyBoneshas left
jonasw
can we agree on #nuketheentiresitefromorbit oracle?
jubalhhas joined
Andrew Nenakhovhas joined
Steve Killehas joined
rionhas left
la|r|mahas joined
intosi has joined
intosi has joined
intosi has joined
alexishas left
alexishas joined
lskdjfhas joined
marchas left
ralphmhas left
intosi has joined
Tobiashas joined
jubalhhas left
ralphmhas joined
alexishas left
SaltyBoneshas joined
Dave Cridlandhas left
ralphmhas left
ralphmhas joined
sezuanhas left
sezuanhas joined
alexishas joined
Valerianhas left
SamWhitedhas left
intosi has joined
intosi has joined
Steve Killehas left
Dave Cridlandhas left
Guushas left
danielhas left
Syndacehas joined
Dave Cridlandhas left
Dave Cridlandhas left
Syndace
Zash: That's the actual question. I don't know, that's why I take the safe route and go with GPL for now.
alexishas joined
Yagizahas left
waqashas left
moparisthebest
do you know oracle actually put a poem as the first bytes in their database protocol?
moparisthebest
specifically on the theory that poems are non-trivial copyrightable works, and that now no one can write an alternative implementation for oracle databases
moparisthebest
oracle is after all, 95% lawyers and 5% programmers right?
About MUJI: https://xmpp.org/extensions/xep-0272.html
The 0.2 is not on the website, an idea?
I found an old version in inbox: https://xmpp.org/extensions/inbox/muji.html (before the 0.1)
-> https://github.com/valeriansaliou/giggle/blob/master/PROTOCOL.md
jonasw
Neustradamus, what are you asking for?
jonasw
0.1 is greater htan the 0.0.0.2 in the inbox
Neustradamus
Yes it is old in inbox
Neustradamus
But there is no 0.2
jonasw
was there ever a 0.2?
Neustradamus
There is not the standard? https://github.com/valeriansaliou/giggle/blob/master/PROTOCOL.md
XMPP Extensions (Updated)
- XEP-0272: Multiparty Jingle (Muji) v0.2
jonasw
dunno where giggle got that v0.2 from
jonasw
but if it’s not on the website, I doubt it exists
jonasw
0.1 is from before the git-svn import
Neustradamus
Ok it confirms my ticket: https://github.com/valeriansaliou/giggle/issues/90
Dave Cridlandhas left
alexishas left
alexishas joined
la|r|mahas joined
Dave Cridlandhas left
LNJhas joined
Dave Cridlandhas left
la|r|mahas left
alexishas left
Dave Cridlandhas left
alexishas joined
ludohas left
ludohas joined
Dave Cridlandhas left
Lancehas left
alexishas left
jubalhhas left
alexishas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
jubalhhas joined
lskdjfhas joined
la|r|mahas joined
Dave Cridlandhas left
alexishas left
Marandahas joined
alexishas joined
MattJhas left
Lancehas joined
Andrew Nenakhovhas left
jubalhhas joined
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Dave Cridlandhas left
j.rhas left
tahas left
tahas joined
alexishas left
Dave Cridlandhas left
alexishas joined
ludohas left
ludohas joined
j.rhas joined
danielhas left
Dave Cridlandhas left
alexishas left
alexishas joined
Holger
Kev: IM-NG currently doesn't allow for sending (delivery) errors to all clients, right?
Holger
Don't we need that?
Kev
Did I miss that out? Full-JID errors go to all clients unless there's an im-ng element.
Kev
(because errors should flip the to/from and therefore will have a full-JID to)
Holger
Ah.
ibikkhas joined
peterhas left
Holger
I don't see this being mentioned, but maybe I'm just overlooking it.
Holger
Kev: And I don't quite get the idea with sending to a single resource? The sender adds an <im-ng/> element, but the recipient should then ignore the message?
Kev
It's a protection (happy to believe I've worded it badly) against having things that look like IM messages, but don't get stored in the archive because of sender trickery.
Kev
So a client should only handle full-JID messages for things that are specifically needing to be full-JID messages.
Holger
Yeah I was going to ask about the meaning of "IM-related messages".
LNJhas left
Kev
But if you received eg. <body>Yep, I'm saying this on the record</body> to a full JID you wouldn't render it in your chat.
Holger
So e.g. a MAM message is not an "IM-related message".
Holger
Right.
Holger
Then again you would render a MAM message :-)
Kev
I also forgot to put any reflection in there.
alexishas left
Kev
But there are words on a (virtual) page now, and that's one step closer.
alexishas joined
Zashhas left
la|r|mahas joined
Dave Cridlandhas left
daniel
So outgoing messages need to be tagged with im-ng? Could the server do that for me?
MattJhas joined
daniel
If I have enabled im-ng in that session
alexishas left
Dave Cridlandhas left
Kev
Yes, I suppose it could.
Kev
Only outgoing messages that are to a full-JID.
alexishas joined
daniel
Example 5 gas that Tag as well though?
Kev
Because I'm an idiot :)
Kev
Gone now.
Dave Cridlandhas left
Kev
Holger: The error confusion is because I messed up. The paragraph should have been:
<p>In order for interoperability with other entities (contacts, remote servers etc.) that don't support IM-NG, old-style full-JID messages also need to be handled. When a server receives a message with type other than than 'groupchat' or 'headline' that does not contain an <im-ng xmlns='urn:xmpp:im-ng:0'> element it is to be routed by the above rules as if they were sent to the bare JID</p>
alexishas left
alexishas joined
Holger
Ah, makes sense.
daniel
Kev: by not process messages to the full jid you mean unless it's a "system message"
daniel
That was somewhat requested
daniel
In the security considerations
Kev
daniel: The text needs massaging. What I really mean is 'if you get a thing to a full JID that you expect to be to a bare JID, ignore it'.
Kev
So if you get a <body>something</body> to a full JID, you'd ignore it.
ralphmhas joined
moparisthebest
couldn't (shouldn't) the server filter that?
Dave Cridlandhas left
daniel
The rules are probably too complex for a sever to grasp
moparisthebest
so another MIX? :P
daniel
I mean in the case of something obvious as body sure
jubalhhas left
alexishas left
alexishas joined
Kev
The server just routes.
Kev
The client gets to decide how to handle what it receives.
moparisthebest
routes and also adds im-ng tag, seems like it could also block bad messages
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
winfriedhas left
Holger
Kev: But what you described regarding error messages would be the regular way of doing things, not just for interop with the old world, no? So if this was *only* mentioned in the above paragraph this intention would still not be obvious to me.
alexishas left
Holger
Kev: The first Business Rule sentence mentions all types except error, I think I'd add a sentence regarding errors following that.