-
jonasw
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
-
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.
-
Zash
"Verkshöjd"
-
jonasw
is that a composed word of some kind? I get "verk", but I can’t interpret "shöjd"
-
Zash
Work-height basically
-
jonasw
ah, that makes sense
-
jonasw
so verks-höjd
-
Zash
Yeah
-
jonasw
yeah, schöpfungs-höhe is creation-height
-
pep.
https://www.fastcompany.com/40547684/slack-picked-a-weird-time-to-make-it-easier-for-bosses-to-download-your-private-chats
-
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 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?
- flow failed using poezio's LMC…
-
jonasw
what
-
jonasw
what would the advantages be?
-
Ge0rG
everybody would see which MUCs you are in!
-
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.
-
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?
-
Syndace
rion: no, it was private until five minutes ago ^^
-
rion
=)
-
Zash
For each client written in python, ask "Does {client} use it already?"
-
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. :)
-
MattJ
Save that for writing servers
-
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.
-
Kev
https://wiki.xmpp.org/web/Minutes_of_the_2018_Summit:_Day_one#1.1._Message_Routing
-
ralphm
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.
-
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
-
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).
-
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
-
ralphm
Or is that not a usecase that is covered by MIX?
-
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
-
Kev
Zash: It's PAMish, yes.
-
Kev
ralphm: You can, it's just a different you.
-
ralphm
Kev: what do you mean?
-
Zash
Bunneh: xep pam
-
Bunneh
Zash: Pubsub Account Management (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0376.html
-
Kev
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.
-
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.
-
ralphm
That'd be great
-
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".
-
Ge0rG
I'm not quite convinced.
-
MattJ
daniel, is it the case that if an oob payload is in a message, Conversations only shows the attachment if <body> == URL?
-
daniel
Either body == oob
-
daniel
Or just oob set and no body
-
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
-
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
-
Zash
moparisthebest: you could, but it'd be ... not nice.
-
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)
-
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
-
moparisthebest
then send the text first :)
-
MattJ
<message><body>----------------</body><hr xmlns="urn:xmpp:hr:0"/></message>
-
moparisthebest
me doing something:
-
moparisthebest
<image here>
-
Kev
MattJ: FWIW, we're currently starting to support this through references.
-
MattJ
Kev, "we"? Swift? XMPP?
-
Kev
Swift.
-
Kev
Initially dealing with images, then looking at other things.
-
MattJ
XEP number..?
-
Kev
(FDP next, which is probably of limited interest to lots of people, but important for us)
-
MattJ
"references doesn't find anything on /extensions/)✎ -
Zash
Kev: Does this include nice ways for bots to attach special annotations?
-
MattJ
"references" doesn't find anything on /extensions/) ✏
-
Zash
-xep references
-
Bunneh
Zash: References (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0372.html
-
Kev
372, although Edwin's about to do an update with more useful stuff like mime types etc.
-
Kev
Zash: Yes.
-
MattJ
Oh, deferred
-
Ge0rG
I fear a bit that 372 is the MIX of message references.
-
MattJ
Ok, so now I have 4 ways to communicate images to clients? :)
-
MattJ
<body>, <html>, <x oob> and <reference>
-
MattJ
and then should be able to support every client
-
Zash
-xep message attaching
-
Bunneh
Zash: Message Attaching (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0367.html
-
MattJ
except Conversations won't show the image even though it could
-
MattJ
Can we just pick one?
-
daniel
I'll probably support Sims at some point
-
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
-
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.
-
MattJ
Send an image with attached text, or text with attached image, whichever way you want to view it
-
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
-
Kev
372 it.
-
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?
-
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
-
Tobias
MattJ, what do you think about 385? But that probably shares similar problems as references. At least on the outer level.
-
MattJ
I don't know yet
-
Kev
https://github.com/xsf/xeps/pull/614 - very basic outline of XMPP 2 IM routing.
-
Kev
ralphm: ^
-
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. ✏
-
Tobias
Kev, nah..you can shove the source hints into references too
-
Tobias
Kev, i guess you could also force a thumbnail into references somehow ;)
-
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
-
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
-
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?
-
Zash
A document describing "Currently, implementations are doing this and that."
-
Zash
And, in a separate document, something of a vision statement.
-
Kev
I think what Zash says has considerable value.
-
Kev
Or something along those lines.
-
MattJ
+1
-
Dave Cridland
I think the two are needed - ie, "this is what is done now", and "this is where we'd like to be".
-
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.
-
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.
-
Zash
Tho I can see how this could be three things
-
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)
-
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.
-
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)
-
Zash
Having snapshots of how the state of things were in the past would be nice to have in the future.
-
Maranda
huhuhuhu http://www.mailenable.com/beta/Premium-ReleaseNotes.txt
-
Maranda
I don't even dare looking.
-
Maranda
But something in there "supports" OMEMO ™ (!)
-
Zash
Kev: `<example caption='Server acknowledges enabling Carbons'>` s/carbons/im-ng/ ?
-
Kev
Yeah. Spot the copy/paste.
-
Dave Cridland
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?
-
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
-
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
-
Maranda
moparisthebest, the funny thing is that they "added" all these features but still manage to not get how to output rfc compliant JSON.
-
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?
-
Zash
Doomed!
-
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.
-
Zash
Are magic numbers copyrightable?
-
daniel
Are you asking oracle that question?
-
jonasw
:(
-
jonasw
can we agree on #nuketheentiresitefromorbit oracle?
-
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.
-
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?
-
Syndace
Why are people like this :O
-
moparisthebest
s/people/lawyers/
-
jonasw
what the actual f*
-
moparisthebest
https://dacut.blogspot.co.uk/2008/03/oracle-poetry.html
-
Neustradamus
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
-
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.
-
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".
-
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.
-
Kev
But there are words on a (virtual) page now, and that's one step closer.
-
daniel
So outgoing messages need to be tagged with im-ng? Could the server do that for me?
-
daniel
If I have enabled im-ng in that session
-
Kev
Yes, I suppose it could.
-
Kev
Only outgoing messages that are to a full-JID.
-
daniel
Example 5 gas that Tag as well though?
-
Kev
Because I'm an idiot :)
-
Kev
Gone now.
-
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>
-
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.
-
moparisthebest
couldn't (shouldn't) the server filter that?
-
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
-
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
-
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.
-
Holger
Kev: The first Business Rule sentence mentions all types except error, I think I'd add a sentence regarding errors following that.
-
Kev
Fair. I was pondering the same, ta.