XSF Discussion - 2018-03-28

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.

like, some constants which are irrelevant to the working of the protocol and are merely there to establish compatbility

jonasw: The being-enough-work-ines?

Zash, yeah, kinda

like, I could probably not claim copyright on a poem like: Foo, the bar, frobnitzed the dingus.

for certain definitions of poem

then again, that might be dadaistic enough to work, but whatevre.

"Verkshöjd"

is that a composed word of some kind? I get "verk", but I can’t interpret "shöjd"

Work-height basically

ah, that makes sense

so verks-höjd

Yeah

yeah, schöpfungs-höhe is creation-height

https://www.fastcompany.com/40547684/slack-picked-a-weird-time-to-make-it-easier-for-bosses-to-download-your-private-chats

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?

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?

what

what would the advantages be?

everybody would see which MUCs you are in!

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.

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

(if you haven't already)

Syndace: does gajim use it already?

rion: no, it was private until five minutes ago ^^

=)

For each client written in python, ask "Does {client} use it already?"

One day I'll make a plugin for Psi to load python extensions =)

I did that with the original plugin implementation about 13 years ago, I think :)

and javascript

Better avoid Lua tho, wouldn't wanna touch a language specifically designed for embedding. :)

Save that for writing servers

Kev: I might have missed it, but is there a writeup for the so-called "xmpp2 routing" stuff discussed at FOSDEM?

(or really, the Summit)

ralphm: https://wiki.xmpp.org/web/XMPP_2.0 is probably the best resource, but pre-summit

ralphm: also https://op-co.de/tmp/whats-wrong-with-xmpp-2017.pdf

ralphm: I think JC sent out minutes from the summit.

https://wiki.xmpp.org/web/Minutes_of_the_2018_Summit:_Day_one#1.1._Message_Routing

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.

ralphm, who is implementing it? I think it's a bit too early and vague for that...

It has multiple unresolved issues

"xmpp 2.0" is more a direction than a protocol

The direction started by Carbons and MAM, prompted by mobile clients and "all messages on all devices" thing?

Zash, I guess. But regardless of that, I don't think there is any denying that the proposed changes simplify a lot of things

MattJ: my own team

MattJ: and I'm talking about MIX, not XMPP 2.0.

MattJ: however, part of MIX in its current form is a dependency on things handled by the participant's local server (roster integration, PAM).

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.

Syndace, +1

Or is that not a usecase that is covered by MIX?

Pretty sure that was part of the whole MIX design. Possibly handled by the pubsub-account stuff?

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.

(or whether this is actually a desirable feature)

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).

Kev: cool. Does it correspond with that wiki page that Ge0rG linked, or is it different from that?

As for selective filtering of pubsub notifications I think that's a thing that is outside MIX or routing-NG.

Daves PAM?

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).

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

Zash: It's PAMish, yes.

ralphm: You can, it's just a different you.

Kev: what do you mean?

Bunneh: xep pam

Zash: Pubsub Account Management (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0376.html

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.

I think this actually goes far beyond pubsub, though.

But I thought you said that with XMPP 2 routing you wouldn't need PAM?

You don't need some aspects of PAM, yea, but you still need something somewhere doing something.

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.

Which goes beyond selective filtering of pubsub notifications.

But does tie into the push and highlighting rules.

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.

Perhaps I should tidy it up a bit and get it submitted so we can have something outside the wiki.

That'd be great

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.

interesting

how do you wrap an IQ into bind2?

Ge0rG: TBD.

But in principle by saying "also activate these things please".

I'm not quite convinced.

daniel, is it the case that if an oob payload is in a message, Conversations only shows the attachment if <body> == URL?

Either body == oob

Or just oob set and no body

Does it use <desc>?

The first one is the one I usually expect. The later is only a bonus if you will

No

i can make it use desc on the sending side if you want me to

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

e.g. I could do: <body>[some description]: [some url]</body> along with the oob payload

But then Conversations wouldn't handle it the "nice way" (and I have no idea about other clients)

what if you just send the image, followed by the description, in 2 different messages?

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

moparisthebest: you could, but it'd be ... not nice.

moparisthebest, not ideal, but I considered it

it's really more supposed to be like a caption for the image/file

or a title, or something

Imagine I sent multiple in a row. It wouldn't be clear if the text applied to the one above or the one below

might just be the only thing that works well across everything *today*, come up with something better for the future :)

`body := url \n desc` would have been nice

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

daniel, is that just because of UI limitations?

the internal db is way too messed up for that

Ok

and UI

but that's more 'solveable' than the db

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)

moparisthebest, except in an IM conversation, the first thing will generally always be text :)

Maybe we should specify a new XEP for <hr> over XMPP

then send the text first :)

<message><body>----------------</body><hr xmlns="urn:xmpp:hr:0"/></message>

me doing something:

<image here>

MattJ: FWIW, we're currently starting to support this through references.

Kev, "we"? Swift? XMPP?

Swift.

Initially dealing with images, then looking at other things.

XEP number..?

(FDP next, which is probably of limited interest to lots of people, but important for us)

Kev: Does this include nice ways for bots to attach special annotations?

"references" doesn't find anything on /extensions/) ✏

-xep references

Zash: References (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0372.html

372, although Edwin's about to do an update with more useful stuff like mime types etc.

Zash: Yes.

Oh, deferred

I fear a bit that 372 is the MIX of message references.

Ok, so now I have 4 ways to communicate images to clients? :)

<body>, <html>, <x oob> and <reference>

and then should be able to support every client

-xep message attaching

Zash: Message Attaching (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0367.html

except Conversations won't show the image even though it could

Can we just pick one?

I'll probably support Sims at some point

5

Or references. What ever the best practices will be

I thought Sims = references

Kinda.

Sims binds a transfer mechanism on top of references.

So it's a Reference with additional information on how to start a file transfer to get it.

I thought Sims binds a green crystal on top of avatar heads.

I think we need to move towards References so we can do things like @mentions and the like sensibly.

-xkcd 927

https://imgs.xkcd.com/comics/standards.png

Kev: how would you attach an image with a reference w/o using Sims?

daniel: http upload URI?

Define 'attach'.

Kev: what about E2EE?

Kev, so to get Swift to do what I want, I should follow XEP-372 or XEP-0385?

It's a reference to a URI, so you provide the image somehow (e.g. HTTP Upload) and then reference it.

I thought that's what Sims was

Only more specific to media

Whereas references are generic

MattJ: What exactly was it you wanted?

daniel: References are fairly generic, and Sims uses References.

Send an image with attached text, or text with attached image, whichever way you want to view it

oob url + desc does what I want already, except it's lacking client support

The image also needs to be transferred? Or that exists already?

I have a URL for it

372 it.

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).

372 feels strange for image attachment

Looks like it wants a character range

Which in my case is easily done - the entire message

whereas "character" is not properly defined.

But if I only set the range to half the message, what would it show?

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.

Also should it hide the referenced text? use it as an alt tag?

We need to have the URI in the body for legacy clients.

It's more interesting when you've got something like @MattJ and you want to link that to the appropriate user in the UI.

Sure, I understand it for that use-case

For my current one however, it feels wrong

Just don't include a range :)

I’d also like to have a range-less thing which uses SIMS syntax. kinda like OOB with more metadata.

but how to handle cases when there /is/ a range

Oh wait, it's optional, ok

MattJ, what do you think about 385? But that probably shares similar problems as references. At least on the outer level.

I don't know yet

https://github.com/xsf/xeps/pull/614 - very basic outline of XMPP 2 IM routing.

ralphm: ^

daniel, but yeah, SIMS is basically references + metadata + source hints on how to get the data

Kev: just in time for Council meeting?

daniel, but i think there are plans to shove metadata into references

And as we're putting metadata into 372 imminently, I guess 385 will move to be References + source hints. ✏

Kev, nah..you can shove the source hints into references too

Kev, i guess you could also force a thumbnail into references somehow ;)

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

yeah i'll let you people figure that stuff out and then just implement what ever the best practices turn out to be

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.

daniel, sensible :)

Or the Compliance Suites remastered as just Current XMPP Version

That's an interesting idea

Hm?

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.

Separation of "This is what's implemented today" and "This is what we want the future to be like" ?

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.

Hm?

A document describing "Currently, implementations are doing this and that."

And, in a separate document, something of a vision statement.

I think what Zash says has considerable value.

Or something along those lines.

+1

I think the two are needed - ie, "this is what is done now", and "this is where we'd like to be".

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.

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.

So, something corresponding to that is what I'm thinking.

Tho I can see how this could be three things

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)

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.

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)

Having snapshots of how the state of things were in the past would be nice to have in the future.

huhuhuhu http://www.mailenable.com/beta/Premium-ReleaseNotes.txt

I don't even dare looking.

But something in there "supports" OMEMO ™ (!)

Kev: `<example caption='Server acknowledges enabling Carbons'>` s/carbons/im-ng/ ?

Yeah. Spot the copy/paste.

Kev, Have you been using my trick of declaring the namespace in an entity to make bumping it easier? :-)

does that even work with CDATA?

jonasw, No, nothing at all works inside CDATA, so i have to terminate the CDATA section, do the entity, and reopen.

Maranda, it doesn't say it supports OMEMO, it says it "Advertises OMEMO Support" :P

jonasw, Saves me remembering what I chose for the namespaces, though.

Dave Cridland, ah that makes sense

moparisthebest, JSXC supports OMEMO *I think*

moparisthebest, else it doesn't make sense

it didn't last time I saw it but that sounds good

moparisthebest, the funny thing is that they "added" all these features but still manage to not get how to output rfc compliant JSON.

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?

Doomed!

jonasw, yeah, that's the reason why I copied these magic values in the first place - to be compatible to the current libsignal clients.

Are magic numbers copyrightable?

Are you asking oracle that question?

:(

can we agree on #nuketheentiresitefromorbit oracle?

Zash: That's the actual question. I don't know, that's why I take the safe route and go with GPL for now.

do you know oracle actually put a poem as the first bytes in their database protocol?

specifically on the theory that poems are non-trivial copyrightable works, and that now no one can write an alternative implementation for oracle databases

oracle is after all, 95% lawyers and 5% programmers right?

Why are people like this :O

s/people/lawyers/

what the actual f*

https://dacut.blogspot.co.uk/2008/03/oracle-poetry.html

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

Neustradamus, what are you asking for?

0.1 is greater htan the 0.0.0.2 in the inbox

Yes it is old in inbox

But there is no 0.2

was there ever a 0.2?

There is not the standard? https://github.com/valeriansaliou/giggle/blob/master/PROTOCOL.md XMPP Extensions (Updated) - XEP-0272: Multiparty Jingle (Muji) v0.2

dunno where giggle got that v0.2 from

but if it’s not on the website, I doubt it exists

0.1 is from before the git-svn import

Ok it confirms my ticket: https://github.com/valeriansaliou/giggle/issues/90

Kev: IM-NG currently doesn't allow for sending (delivery) errors to all clients, right?

Don't we need that?

Did I miss that out? Full-JID errors go to all clients unless there's an im-ng element.

(because errors should flip the to/from and therefore will have a full-JID to)

Ah.

I don't see this being mentioned, but maybe I'm just overlooking it.

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?

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.

So a client should only handle full-JID messages for things that are specifically needing to be full-JID messages.

Yeah I was going to ask about the meaning of "IM-related messages".

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.

So e.g. a MAM message is not an "IM-related message".

Right.

Then again you would render a MAM message :-)

I also forgot to put any reflection in there.

But there are words on a (virtual) page now, and that's one step closer.

So outgoing messages need to be tagged with im-ng? Could the server do that for me?

If I have enabled im-ng in that session

Yes, I suppose it could.

Only outgoing messages that are to a full-JID.

Example 5 gas that Tag as well though?

Because I'm an idiot :)

Gone now.

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 &lt;im-ng xmlns='urn:xmpp:im-ng:0'&gt; element it is to be routed by the above rules as if they were sent to the bare JID</p>

Ah, makes sense.

Kev: by not process messages to the full jid you mean unless it's a "system message"

That was somewhat requested

In the security considerations

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'.

So if you get a <body>something</body> to a full JID, you'd ignore it.

couldn't (shouldn't) the server filter that?

The rules are probably too complex for a sever to grasp

so another MIX? :P

I mean in the case of something obvious as body sure

The server just routes.

The client gets to decide how to handle what it receives.

routes and also adds im-ng tag, seems like it could also block bad messages

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.

Kev: The first Business Rule sentence mentions all types except error, I think I'd add a sentence regarding errors following that.

Fair. I was pondering the same, ta.