jonaswmoparisthebest, 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.
jonaswlike, 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
Zashjonasw: The being-enough-work-ines?
jonaswZash, yeah, kinda
jonaswlike, I could probably not claim copyright on a poem like:
Foo, the bar, frobnitzed the dingus.
jonaswfor certain definitions of poem
jonaswthen again, that might be dadaistic enough to work, but whatevre.
Dave Cridlandhas left
Zash"Verkshöjd"
danielhas left
jonaswis that a composed word of some kind? I get "verk", but I can’t interpret "shöjd"
flowI 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?
flowI 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
jonaswwhat
jonaswwhat would the advantages be?
j.rhas joined
Ge0rGeverybody 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
SyndaceThere 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
MattJSyndace, 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)
rionSyndace: does gajim use it already?
Guushas left
LNJhas left
Syndacerion: no, it was private until five minutes ago ^^
alexishas left
rion=)
ZashFor each client written in python, ask "Does {client} use it already?"
alexishas joined
rionOne day I'll make a plugin for Psi to load python extensions =)
KevI did that with the original plugin implementation about 13 years ago, I think :)
rionand javascript
ZashBetter avoid Lua tho, wouldn't wanna touch a language specifically designed for embedding. :)
ludohas left
ludohas joined
MattJSave that for writing servers
Zashhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
alexishas left
alexishas joined
marmistrzhas left
j.rhas joined
ralphmKev: 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)
Ge0rGralphm: https://wiki.xmpp.org/web/XMPP_2.0 is probably the best resource, but pre-summit
Ge0rGralphm: also https://op-co.de/tmp/whats-wrong-with-xmpp-2017.pdf
Kevralphm: I think JC sent out minutes from the summit.
ralphmThanks. 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
MattJralphm, who is implementing it? I think it's a bit too early and vague for that...
MattJIt has multiple unresolved issues
MattJ"xmpp 2.0" is more a direction than a protocol
alexishas left
alexishas joined
ZashThe direction started by Carbons and MAM, prompted by mobile clients and "all messages on all devices" thing?
MattJZash, I guess. But regardless of that, I don't think there is any denying that the proposed changes simplify a lot of things
ralphmMattJ: my own team
ralphmMattJ: and I'm talking about MIX, not XMPP 2.0.
ralphmMattJ: 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
ralphmI'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.
flowSyndace, +1
lskdjfhas joined
alexishas left
alexishas joined
j.rhas joined
ralphmOr is that not a usecase that is covered by MIX?
moparisthebesthas joined
alexishas left
alexishas joined
ZashPretty sure that was part of the whole MIX design. Possibly handled by the pubsub-account stuff?
ralphmWell, 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)
Kevralphm: 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).
ralphmKev: cool. Does it correspond with that wiki page that Ge0rG linked, or is it different from that?
KevAs for selective filtering of pubsub notifications I think that's a thing that is outside MIX or routing-NG.
ZashDaves PAM?
KevI'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).
ralphmKev: ok, but I'm still curious how it works, because now you're subscribed with the bare JID, you can't use CAPS filtering
Kevralphm: 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.
KevI think this actually goes far beyond pubsub, though.
ralphmBut I thought you said that with XMPP 2 routing you wouldn't need PAM?
KevYou don't need some aspects of PAM, yea, but you still need something somewhere doing something.
KevTake 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.
KevWhich goes beyond selective filtering of pubsub notifications.
KevBut does tie into the push and highlighting rules.
alexishas left
KevI 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.
KevPerhaps 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
ralphmThat'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
KevI'm going to make activation of IM-NG an iq after bind, on the basis that it can then be wrapped up inside bind2.
ralphminteresting
Ge0rGhow do you wrap an IQ into bind2?
KevGe0rG: TBD.
KevBut in principle by saying "also activate these things please".
alexishas left
Ge0rGI'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
MattJdaniel, 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
danielEither body == oob
alexishas joined
danielOr just oob set and no body
tahas joined
MattJDoes it use <desc>?
danielThe first one is the one I usually expect. The later is only a bonus if you will
danielNo
danieli can make it use desc on the sending side if you want me to
MattJTrying 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
MattJe.g. I could do: <body>[some description]: [some url]</body> along with the oob payload
MattJBut then Conversations wouldn't handle it the "nice way" (and I have no idea about other clients)
moparisthebestwhat if you just send the image, followed by the description, in 2 different messages?
MattJas 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
Zashmoparisthebest: you could, but it'd be ... not nice.
Andrew Nenakhovhas joined
MattJmoparisthebest, not ideal, but I considered it
MattJit's really more supposed to be like a caption for the image/file
MattJor a title, or something
MattJImagine I sent multiple in a row. It wouldn't be clear if the text applied to the one above or the one below
moparisthebestmight 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
danieldon‘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
MattJdaniel, is that just because of UI limitations?
danielthe internal db is way too messed up for that
MattJOk
danieland UI
danielbut that's more 'solveable' than the db
moparisthebestMattJ, 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
MattJmoparisthebest, except in an IM conversation, the first thing will generally always be text :)
MattJMaybe we should specify a new XEP for <hr> over XMPP
MattJexcept Conversations won't show the image even though it could
alexishas left
MattJCan we just pick one?
alexishas joined
danielI'll probably support Sims at some point
jjrhhas left
MattJ5
danielOr references. What ever the best practices will be
danielI thought Sims = references
KevKinda.
KevSims binds a transfer mechanism on top of references.
KevSo it's a Reference with additional information on how to start a file transfer to get it.
Ge0rGI thought Sims binds a green crystal on top of avatar heads.
KevI think we need to move towards References so we can do things like @mentions and the like sensibly.
Zash-xkcd 927
Bunnehhttps://imgs.xkcd.com/comics/standards.png
danielKev: how would you attach an image with a reference w/o using Sims?
Ge0rGdaniel: http upload URI?
KevDefine 'attach'.
Ge0rGKev: what about E2EE?
MattJKev, so to get Swift to do what I want, I should follow XEP-372 or XEP-0385?
KevIt's a reference to a URI, so you provide the image somehow (e.g. HTTP Upload) and then reference it.
danielI thought that's what Sims was
danielOnly more specific to media
danielWhereas references are generic
KevMattJ: What exactly was it you wanted?
Kevdaniel: References are fairly generic, and Sims uses References.
peterhas joined
alexishas left
MattJSend an image with attached text, or text with attached image, whichever way you want to view it
alexishas joined
MattJoob url + desc does what I want already, except it's lacking client support
KevThe image also needs to be transferred? Or that exists already?
MattJI have a URL for it
SamWhitedhas left
Kev372 it.
SamWhitedhas joined
KevI 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).
MattJ372 feels strange for image attachment
MattJLooks like it wants a character range
MattJWhich in my case is easily done - the entire message
jonaswwhereas "character" is not properly defined.
MattJBut if I only set the range to half the message, what would it show?
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
KevIn 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.
Ge0rGAlso should it hide the referenced text? use it as an alt tag?
Ge0rGWe need to have the URI in the body for legacy clients.
KevIt's more interesting when you've got something like @MattJ and you want to link that to the appropriate user in the UI.
MattJSure, I understand it for that use-case
MattJFor my current one however, it feels wrong
KevJust don't include a range :)
jonaswI’d also like to have a range-less thing which uses SIMS syntax. kinda like OOB with more metadata.
jonaswbut how to handle cases when there /is/ a range
MattJOh wait, it's optional, ok
alexishas left
alexishas joined
alexishas left
TobiasMattJ, 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
MattJI don't know yet
Kevhttps://github.com/xsf/xeps/pull/614 - very basic outline of XMPP 2 IM routing.
Kevralphm: ^
lovetoxhas joined
Tobiasdaniel, but yeah, SIMS is basically references + metadata + source hints on how to get the data
Ge0rGKev: just in time for Council meeting?
KevAnd as we're putting metadata into 372 imminently, I guess 385 will move to be References source hints.
Tobiasdaniel, but i think there are plans to shove metadata into references
KevAnd as we're putting metadata into 372 imminently, I guess 385 will move to be References + source hints.
alexishas joined
TobiasKev, nah..you can shove the source hints into references too
marchas left
TobiasKev, i guess you could also force a thumbnail into references somehow ;)
alexishas left
MattJI'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
danielyeah i'll let you people figure that stuff out and then just implement what ever the best practices turn out to be
KevMattJ: 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.
Tobiasdaniel, sensible :)
KevOr the Compliance Suites remastered as just Current XMPP Version
SamWhitedThat's an interesting idea
alexishas left
ZashHm?
SamWhitedI 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.
ZashSeparation of "This is what's implemented today" and "This is what we want the future to be like" ?
SamWhitedI 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.
ZashHm?
ludohas joined
Yagizahas joined
ZashA document describing "Currently, implementations are doing this and that."
ZashAnd, in a separate document, something of a vision statement.
Dave Cridlandhas left
KevI think what Zash says has considerable value.
remkohas joined
KevOr something along those lines.
lovetoxhas left
MattJ+1
alexishas joined
Dave Cridlandhas left
tuxhas joined
Dave CridlandI think the two are needed - ie, "this is what is done now", and "this is where we'd like to be".
tuxhas left
KevI 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
ZashIn 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.
ZashSo, something corresponding to that is what I'm thinking.
la|r|mahas left
ZashTho I can see how this could be three things
Dave Cridlandhas left
Zash1) 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
KevI 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
ZashKev: 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
ZashHaving snapshots of how the state of things were in the past would be nice to have in the future.
moparisthebestit 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
Marandamoparisthebest, 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
jonaswSyndace, 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
ZashDoomed!
Dave Cridlandhas left
Syndacejonasw, 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
ZashAre magic numbers copyrightable?
danielAre you asking oracle that question?
jonasw:(
SaltyBoneshas left
jonaswcan 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
SyndaceZash: 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
moparisthebestdo you know oracle actually put a poem as the first bytes in their database protocol?
moparisthebestspecifically on the theory that poems are non-trivial copyrightable works, and that now no one can write an alternative implementation for oracle databases
moparisthebestoracle is after all, 95% lawyers and 5% programmers right?
NeustradamusAbout 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
jonaswNeustradamus, what are you asking for?
jonasw0.1 is greater htan the 0.0.0.2 in the inbox
NeustradamusYes it is old in inbox
NeustradamusBut there is no 0.2
jonaswwas there ever a 0.2?
NeustradamusThere is not the standard? https://github.com/valeriansaliou/giggle/blob/master/PROTOCOL.md
XMPP Extensions (Updated)
- XEP-0272: Multiparty Jingle (Muji) v0.2
jonaswdunno where giggle got that v0.2 from
jonaswbut if it’s not on the website, I doubt it exists
jonasw0.1 is from before the git-svn import
NeustradamusOk 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
HolgerKev: IM-NG currently doesn't allow for sending (delivery) errors to all clients, right?
HolgerDon't we need that?
KevDid 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)
HolgerAh.
ibikkhas joined
peterhas left
HolgerI don't see this being mentioned, but maybe I'm just overlooking it.
HolgerKev: 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?
KevIt'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.
KevSo a client should only handle full-JID messages for things that are specifically needing to be full-JID messages.
HolgerYeah I was going to ask about the meaning of "IM-related messages".
LNJhas left
KevBut 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.
HolgerSo e.g. a MAM message is not an "IM-related message".
HolgerRight.
HolgerThen again you would render a MAM message :-)
KevI also forgot to put any reflection in there.
alexishas left
KevBut 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
danielSo outgoing messages need to be tagged with im-ng? Could the server do that for me?
MattJhas joined
danielIf I have enabled im-ng in that session
alexishas left
Dave Cridlandhas left
KevYes, I suppose it could.
KevOnly outgoing messages that are to a full-JID.
alexishas joined
danielExample 5 gas that Tag as well though?
KevBecause I'm an idiot :)
KevGone now.
Dave Cridlandhas left
KevHolger: 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
HolgerAh, makes sense.
danielKev: by not process messages to the full jid you mean unless it's a "system message"
danielThat was somewhat requested
danielIn the security considerations
Kevdaniel: 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'.
KevSo if you get a <body>something</body> to a full JID, you'd ignore it.
ralphmhas joined
moparisthebestcouldn't (shouldn't) the server filter that?
Dave Cridlandhas left
danielThe rules are probably too complex for a sever to grasp
moparisthebestso another MIX? :P
danielI mean in the case of something obvious as body sure
jubalhhas left
alexishas left
alexishas joined
KevThe server just routes.
KevThe client gets to decide how to handle what it receives.
moparisthebestroutes 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
HolgerKev: 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
HolgerKev: The first Business Rule sentence mentions all types except error, I think I'd add a sentence regarding errors following that.
XSF Discussion - 2018-03-28