XSF Discussion - 2017-11-08

Wow, that looks cool

Right now there is a "math party" at my university

https://jabberhead.tk:5443/f0a454a3b03d017a262dfcfef56c2235742e325d/zCMPkHkA5MltD4QQtF25Lqlw4PglxRCG2zKXN5pn/ka4RoLEzQjWNyTtzwEF-VA.jpg

daniel: minor annoyance report: despite having looked at the rules in the past I am never sure why some links (like vanitasvitae 's) show up as downloadable but others (Arc's) are not.

SamWhited: maybe because mine is a httpupload link?

Ah, maybe thats not the reason...

yah, as far as my client is concerned its just a message with text in it that looks like a link (unless the MUC is also reflecting OOB metadata or something)

Not a big deal, it just "feels" inconsistent

SamWhited: if you use the attach button in Conversations it will add an oob tag. And Conversations will only show the button for messages which also have an oob tag

The muc does reflect that

That makes sense

well one's http vs https

is the mime being sent on each?

moparisthebest: FWIW I've had thoughts along the same lines as you wrt encrypting things separately so that only the entity that needs one piece of data can see it. But I don't think that's XMPP.

How does the OOB tag interop with OMEMO? It's obviously leaking data, but what exactly? Is the password only contained in the body?

I am under the impression that it's just a special URL in the (encrypted) body, with the encryption key in the #this part.

leaking data my ass...

yet another round of bikeshedding

Zash: yes, that's how it works. But what is contained in the oob tag?

I would look up myself, but I don't have any OMEMOs

I don't believe there is one

Zash: I was under the impression that Conversations needs the oob tag to display inline images

Ge0rG: oob is safe enough for daniel, sims would not be: https://github.com/siacs/Conversations/issues/2637

I'd probably consider the picture URL and file size to be private as well, but what do I know

Where's that blag that said that e2e crypto is basically just marketing fluff?

Hm. of all people, I should know that.

SamWhited, so you’re arguing my proposal is bad because it’ll lead to incompatibilities among clients, but you argue that incompatibilities among clients when you change bits in yours aren’t an issue? (around 22:19Z)

daniel, no, you will only get real-world feedback on the input format. nobody cares about the wire format except the devs who are then forced to implement things because of your market share (sorry to be blunt here.) (re around 22:48Z)

but hey, we already agree on the input format, I think that’s really nice, and it’s nice to have that standardised.

I only wish for a way to skip formatting when typing formulas

or any other content which shouldn’t be formatted for that matter. ✏

but nobody listens to me

It seems weird to me to be XEPing what amounts to UI things

Zash: because you are a server dev

Zash: I care very much about UI things, and I want them consistent across implementations

I'm sure everybody already noticed that XHTML-IM/styling/markdown/bmh discussion related thing on HN: https://news.ycombinator.com/item?id=15646425

This is the major weakness of XMPP. Every client works differently

But sometimes it is a strength.

depends

I think for each major workflow we’d need a set of clients covering each platform.

Altho according to some random Reddit thread I saw, none of the competition things work as they should in FOSS

currently, conversations covers the "non-technical" workflow pretty well on mobile.

Zash: yes, if you believe that you need the opportunity to differentiate on quality of implementation.

Well, optimally the differentiation would be on proirites, so you could find a thing that sucks in ways you don't care about.

jonasw, a while ago Dave suggested to have a generic extension to reference certain parts of bodytext ( https://mail.jabber.org/pipermail/standards/2016-February/030924.html ). That doesn't sound like a bad idea to me, as it could also be used in your Message Markup XEP. What do you think?

Flow, I looked at References

it would be a major (size) overhead to have a <reference xmlns="…"> element for each bit of markup though

jonasw, not reference

<bodytext/>

(see linked mail)

Uh wait, maybe I misunderstood Dave's mail, he was probably just talking about factoring the data into an extra element

not using that as generic element which can be re-used by other xeps

I think so, too

but now I get what you meant

it also isn’t in the final XEP

(<https://xmpp.org/extensions/xep-0372.html>)

true, but the idea is appealing. such an generic element could also specify how it's used with non-<body/> body text

like the text found in OMEMO messages

I see your general point. we could reword so that it doesn’t refer to <body/> but to "text of the message". in which case OMEMO would provide the "actual" text of the message as opposed to the <body/>.

but there are different issues with combining this with OMEMO which need to be discussed in the security considerations (OMEMO won’t encrypt the markup...)

jonasw, i fear it's a bit more complicated than that

(nor will it authenticate the markup, which is bad too)

Flow, is it?

1. there could be multiple unencrypted <body/> elements. 2. with OX there could be multiple encrypted <body/> elements. 3. with omemo it is just one body (and the markup information is not encrypted/authenticted)

multiple unencrypted body elements must have xml:lang tags to distinguish them, as do <markup/> elements.

I presume that this is the same for OX?

yep

What does happen if you have multiple bodies with e2e?

but I possibly place the xml:lang selector not in <markup/> but in the generic <bodytext/>

Zash, what happens if you have multiple bodies without e2e?

Flow, that makes things more complex to parse and generate I think

I haven't a clue

Flow, I think e2ee simply doesn’t allow that

it’s also not a very common use-case in IM

OX does not forbit multiple <body/> elements

*forbid

*currently deployed e2ee simply doesn’t allow that ;-)

Is there an OX implementation in smack Flow?

daniel, there is a branch a started a while ago

but nothing even prototypical

yet

jonasw: maybe you should cover the case in markups. How does it work when there are multiple bodies ATM? (Different xml:lang)

first ISR, then OX. that is the current order of my priorities ;)

pep., it’s in the Business rules and the Internationalisation considerations.

jonasw: also, unrelated, I'm not really fan of leaving the list/quotation characters etc., in the rendered version

pep., I agree

it’s tricky to avoid though

I’m writing a response to standards@ about this

K

(Goffi brought it up there)

Will read

And I need to reply as well

pep., there you go

jonasw: aren't the > and * you use in your example kinda like markup information in the body?

Which the xep says you are trying to avoid?

That's why I don't like them

daniel, It's only bad if someone else does it.

daniel, it’s not required for them to be there at all.

they don’t carry any meaning.

however, if combined with Message Styling, I can totally see letting them in there for compatibility.

What's the point if you already have the meaning of your markup translated

pep., Fallback.

you can’t stop people from typing them (I do too!), and I’m totally in favour of specifying the input format Message Styling defines

And then we end up with a message containing a <body> with this-is-really-not-markdown-although-it-walks-like-markdown-and-quacks-like-markdown, a <body-markup-hint/>, a <markup> tree and an XHTML-IM payload.

but in contrast to the Message Styling wire format, we could adapt to changing behaviours and trends in the meta-characters used by humans

which is nice

(I mean, adapt without breaking old archives and interop for the transition period)

jonasw: leaving it there defeats the point of not putting markup on the body

pep., tend to agree.

but some kind of fallback is needed.

Why?

especially for quotations

(not so much for lists)

My thoughts on this, /still/ not having had time to look at the spec. Is that we're not trying to define a new format here that adds a new feature, we're trying to render correctly what the user's intent was when they typed something. I think that changes things *significantly*.

if a client doesn’t understand <markup/>, it would render the quotations as normal paragraphs.

Do we have a failback for every single xep out there? In case the first one isn't supported

pep., I think most XEPs either specify a fallback or fail gracefully.

And so just documenting roughly what people are already typing in messages is both pragmatic and sensible.

(And people *are* already typing ascii markup in messages, and the world is definitely not falling apart, even though not all clients support rendering it)

Kev, my main problem with Message Styling isn’t that it does that, but that it doesn’t have an opt-in.

Kev: actually, all clients support rendering it... as ASCII

Ge0rG: agreed

Ge0rG: Potato potato :)

if we’re going to change the rendering with possibly removing charatcers (e.g. for quotations!), then it must be opt-in.

We should not be removing characters.

and I think that it should still be opt-in even if those characters are preserved.

jonasw, isn't opt-in something your client should support?

daniel, no, because the client can’t know if the sender intended it.

We should be rendering the existing characters with additional styling, or should have a local toggle.

Kev: but it's up to the sender to decide whether they want markup for a given ASCII sequence.

(Which is what Swift does with emoticons - it renders by default, removing the source, but you can flip it off to go back to the as-sent. Useful if someone's pasting code sometimes)

i'm not really sure what you mean by opt-in then

daniel, an additional element to <message/> which indicates that the body can be interpreted according to the Message Styling rules.

I think that when copy&pasting things from the IM client, the original body should be copied with all "markup" characters present as-is

jonasw: that would be body-markup-hints?

jonasw, i can get on board with that

Ge0rG, exactly.

daniel, I said so on the list, nobody cared :(

the sending client could pre-render markup in the input field and offer a button to strip markup

so you can paste code.

but then interop.

You can't fix Gajim overnight

Ge0rG, lovetox can :)

So we need two hints. One for "this is markup" and another for "this is definitively not markup"

i'm not really sure I want Flows xep for that though. because then styling would depend on Flows xep getting accepted

daniel, I think flows xep was rejected anyways?

Ge0rG: Isn't this similar to the "I meant what I sent" that I was talking about with not doing emoticon rendering?

daniel, It needs something like Flow's BMH. Not *exactly* it.

dwd, I think in fact it pretty much needs that.

(Although not quite the same)

Kev: I thought you were talking about the receiving side

I'm still annoyed by some IM clients replacing (b) and (y) with random emoji.

daniel, in fact, my arguments for opt-in were dismissed with something along the lines of "edge cases nobody should care about".

Ge0rG, kill trillian with fire

jonasw: also, Gajim.

jonasw, i'm trying to find your email in that huge bike shadding thread to give a thumbs up

Date: Yesterday 19:29

(CET)

if that helps

destroyallsoftware?

it does

Kev: "I meant what I sent" could be a BMH of "text/plain"

Ge0rG, I don't think we need the complexity of media typing here, actually.

dwd: right, let's just invent a new name for it.

Ge0rG, Would you want text/html there?

I get shivers.

also, note that BMH is not Content types

Ge0rG, If anything, we want a media type of: `text/plain; format=XYZ`, with ZYX given by a BMH-a-like.

Okay, BMH only relates to body, so "text/" is implicitly pre-set.

https://xmpp.org/extensions/inbox/bmh.html#languages

there’s no media type here.

I don't like the use of the term "Language" in there.

</bikeshed>

Ge0rG, Yes, excellent point, this is veyr much a bikeshed.

BMH essentially foresaw Styling.

> TODO: Shall we define your own subset of e.g. CommonMark, XMPPMark? :)

(or shall I say, inspired?)

I think the writing was on the wall.

dwd: as opposed to the exact BMH identifier string to be used for "this is not markup"?

Only we couldn't parse it properly because it turned out nobody knew what *this* meant.

I still want code syntax highlighting.

Ge0rG, I'm not worried about clients heuristically doing that in ```these sections```.

What about `if(what){then()}`{.c}

like heuristically rendering /italics/ and *bold*?

Zash: I think it's sensible to keep syntax coloring to ``` blocks, not to `spans`

So what about the following proposal: - messages with a BMH(*) of "Styling" get styled and the markup characters removed on display (but not on copy&paste) - messages without a BMH get rendered as markup with the markup charachters in place - messages with a BMH of "plain" get rendered verbatim with no styling applied (*) BMH or an improved version that provides the same semantical meaning

Ge0rG, I think that's sensible. I'm not entirely sure about the middle case, but I don't care enough to object.

gajims current rendering is pretty annoying btw

daniel, didit boldface everything between (*) and (*)?

yes

kill it with fire

jonasw, Yup. Not a huge fan of that, nor leaving the *asterisks* in place.

jonasw, But as a heuristic solution it's OK, and 99% of the time gets things right.

Ge0rG, you can’t really remove the markup characters on display in any case, because then clients would have to be sure that the sender intended it to be that way.

x * y - z * 3

easy to writer a parser they said

Ge0rG, and I don’t think that’s an assumption an client operated by a human can reasonably have

jonasw, Ge0rG literally just outlined a way to communicate exactly that.

jonasw: the sender needs to pre-render the markup in the input line of course.

zinid, the styling xep has a very straight forward parser

dwd, sender as in the human operating the client, not as in the program

it's just about defining the rules properly

Ge0rG, that’s a very complex thing not many clients will do.

jonasw: an easier thing would be to have a button on the sent message to "remove markup", which would send an LMC with a BMH.

daniel: can I use LALR(1) parser? if not, it's not simple

Ge0rG, sounds like a plan!

didn’t think of LMC in this context, kudos

zinid, I think LALR(1) should do

jonasw: can I have grammar.y then? or should I write it manually because it's funny?

zinid, I suggest that the XEP authors provide a formal definition of the grammer once it is accepted :)

jonasw: ok

BNF FTW!

ABNF would be awesome, I could use ragel

ABNF seems very reasonable considering that it’s the IETFs go-to representation for grammars.

Ge0rG, if we want to annotate i'd prefer the simpler 'opt-in' proposal jonasw had

Not EBNF?

Zash, I always forget the exact acronym

you could still to 'send lmc to remove style'

daniel: the simpler opt-in mechanism requires all clients to update

daniel: ah, LMC-based markup removal. Yeah.

jonasw: Looks like both ABNF and EBNF exist

daniel, re-visiting BMH in the light of Styling I think BMH would be a great way to convey this and allow for richer use-cases at the same time.

Ge0rG, most clients need to update anyway. because gajim doesn't support styling for example

BMH still can’t cover everything XHTML-IM could, but it provides nice plain-text fallbacks. a client with strong a11y considerations would want to interpret most of those markups anyways.

Ge0rG, re code blocks, by the way, a common convention is "```language\n<code here>\n```"

that’s how gitlab markup does it

jonasw: yeah, I could live with that.

That's how pandoc does it.

re "text/plain", Tobias wrote re BMH: "I wonder whether it makes sense to reuse IANA Media Types instead of starting a new registry."

Ge0rG, at which point it would’ve been Content Types (<https://xmpp.org/extensions/inbox/content-types.html>) which was rejected over a year ago

History is repeating.

Can't we just change the message type? (I mean the 'type' attribute of the <message> stanza)

Ge0rG, go away.

;-)

Ge0rG, i think the RFC doesn't allow additional parameters on that

or additional attributes on body

namespaced attributes! (Sam is gonna shoot me)

Tobias: we can override the RFC with an XEP. I'm sure nobody will notice.

jonasw: y u do this

Zash, what?

jonasw: mention namespaced attributes :)

I think they’re great.

do they need namespace versioning as well?

sure

I think by now that much of this war is rooted in the confusion between "plain-text fallback" and "markup language" and that again is rooted in the fact that many modern markup languages look like plaintext fallbacks.

or rather have useful plaintext fallbacks right from the beginning

Well, also whether you want what people already type to be correctly handled everywhere.

Kev, no, that’s input conventions and should not matter for wire formats.

Assuming universal adoption.

But this 'just render what's sent with styling enhancement' has been in use for a very long time without issue.

if we still had the IRC conventions with some control-characters for formatting around, you’d not argue that "what people already type" should be in wire formats.

(mostly because XML can’t carry those, but also because it’s not a useful plaintext fallback)

I like arguments like "everyone is already doing it" and "has worked forever without issue"

Kev, I doubt you can say "without issue" just 50 lines after somebody complained about how broken gajim handles that.

Especially when people are pointing out the times it's messy and doesn't work

jonasw, which is why I’ll write a protoxep in order to send the poezio internal format over the wire, escaped ✏

jonasw: Gajim may do something stupid, but Psi doesn't.

I'm not saying that doing other things than what I'm suggesting works without issue :)

Kev, but it kind-of moots the "everyone is doing it and it works great" point

"psi is doing it, and for some cases it works great" already doesn’t sound that good

It would certainly bring into question that point that I'm not making, yes.

A lot of people are sending this stuff on the wire, irrespective of rendering. Some clients (at least Psi) also add styling successfully to it.

Kev, "without issue" is certainly wrong, but I’m not going to nitpick here (and I probably misread some statement)

What's the issue with what Psi's doing?

I don’t know psi, but what gajim does is certanily an issue.

so it’s not without issue at all.

It basically just turns *thing* into <b>*thing*</b>

jonasw, Kev’s point is that it has been in use for a long time without issue, in psi

which is not contradicted by "gajim handles things wrong"

I don't buy the argument that "What Kev suggests doesn't work, because someone does something different to what Kev suggests, and that doesn't work".

Kev, maybe I missed what you indeed suggest :)

(I haven’t used psi in a very long time so I can’t argue with that)

Just adding styling to ** // __.

Kev, well gajim does exactly that

(Without removing the characters)

If Gajim does exactly that, what's the issue?

it also does that across newlines

jonasw, gajim has somewhat looser boundaries

I think psi only does it for words

mathieui, Kev didn’t say anything about boundaries :-)

e.g. the formating chars are stuck to the words

Kev: even by keeping the formatting characteres, I would not like to have ls `date +%Y-%m-%d`-*.xml rendered half in monospace, partly in bold. How does Psi handle that?

I forget, I wrote this a decade and a half ago or so.

jonasw, I mean, if Kev says it works fine, it has to be slightly more precise than what gajim does, even if I believe we can always find cases where it doesn’t do what's intended

I'm sure it's possible to have it do not-what-you-intend, but I don't believe ever in a way that damages the ability to understand it.

But none of that example should be bold, because there's only one *, and in that particular case half of it being monospace is exactly what one would usually expect.

But ISTR I made Psi not do word partials.

FTR, I think the rules laid out by Styling are a good start, once we get rid of the escaping (which I think Sam said he would do)

There *is* a definite advantage to having this out of band, BTW, which is that you can not annotate things that are pastes.

But I think you can achieve the same thing just by having <paste/> as a child.

AFK a while.

I can see it now, 20 years from now: "daddy what caused the great XMPP fork of 2017 when half the community split off into Zimpy?" "well honey, they couldn't agree on the optimal way to bold a word in a text message"

/thread

itym </thread>?

*thread*

*italics*

i*italics*

["The last word should be ", {"style": "bold", "contents": "bold"}]

Let me tell you about `pandoc -t json`

Can I still say no?

Or rather, [{"unMeta":{}},[{"t":"Para","c":[{"t":"Str","c":"No!"}]}]]

I'm concerned that "No" is not semantically transmitted, and therefore may be interpreted differently in multiple clients.

dwd: I see that you're married.

We should have a markup that encapsulates the entirety of human speech, so that all clients directly interpret the semantics intended, and therefore can respond suitably without relying on humans having to guess what the sender might mean.

<statement><negative exclamation='true'>no</negative></statement>

dwd: machine to machine communications?

Guus, <amusement/><agreement/>

Ge0rG, And from there, but a short step to eliding the communication entirely, making XMPP so much more bandwidth efficient.

I would propose BER, but I'm too lazy to do so.

B2B communication

intosi, PER, surely, or does David no longer get excited by that one?

intosi: have you considered beer instead

dwd: that's absolutely the wrong direction. We can finally increase XMPP's popularity by populating the network with m2m semantics-capable clients

Zash: +1

dwd: I am not presently in the same room as David, he cannot complain.

<ironic-statement/>

<sarcastic-retort/>

<assertion-of-fascism/>

<godwins-law/>

<statement:nonsensical rel='plankton'/>

I'm super sorry to turn the topic of conversation here, but, Zash about layers of encryption so each server only knew bare minimum

seems like it could still be XMPP but we'd just have to wrap things in new nonzas ?

moparisthebest, broadcast

"We can finally increase XMPP's popularity" - this will never happen

<deliver to="otherserver.com"> (this part is encrypted blob #1)<deliver to="jid@otherserver.com">(this part is encrypted blob #2)<message from="bob@bob.com" to="jid@otherserver.com">etc</message>(/end encrypted blob #2)</deliver>(/end encrypted blob #1)</deliver>

moparisthebest, what about presence broadcast, MUC?

jonasw, not sure, maybe it only works for messaging

MUC and MIX broadcasts?

jonasw: encrypted to the MUC service

jonasw: or multi-key-encrypted to all participants

it might only be feasible for bare-minimum metadata for direct chats

yea that'd work I guess, let the MUC service broadcast, idk

just trying to throw crazy ideas out there that solve the metadata problem as much as possible

I don’t think that there is a real metadata problem.

we are OK with specs that require changes on all clients and servers to be useable already, see MIX

or maybe there is, but I don’t think it’s reasonable to solve that within XMPP.

might as well solve the metadata problem the same way

moparisthebest: the best solution to the metadata problem is to run your own server for you and all of your important contacts

jonasw: no, I'm arguing that it's not a problem because we won't change it later. The formatting is good enough and doesn't need to be extensible after we settle on a few basic things (but I don't remember what I said about your thing with relation to compatibility)

doesn't *solve* it, you still have 1 central service that knows everything

moparisthebest: solve what?

moparisthebest: federated systems will always have metadata leakage. What you want instead is a P2P DHT chat system.

SamWhited, okay

metadata problem

moparisthebest: or maybe you want to connect to XMPP via TOR.

if I wanted that I'd just use tox, and have to change my phone battery every 20 minutes

I'm just talking about leaking bare minimum metadata to XMPP servers, the bare minimum for federated chat

moparisthebest: so what you want instead is a tox agent running on a trusted server that you connect to.

then you are back to 1 central server with all info

moparisthebest: yes.

so you've got A (client) -> B (server) -> C (server) -> D (client)

moparisthebest: with XMPP, you could hide the usernames of the people you talk to from your server. But not presence.

an ideal scenario has each only knowing about the next hop

moparisthebest: and then still, the receiving server would know your full JID.

no they'd only know the server it came from, and who it's going to, not sending JID though

moparisthebest, that doesn’t buy you a lot, you’d need to go full Tor essentially

I think it does buy you a lot

no server knows who sent it or who it's intended for

and that's the win you are looking for

worded that wrong, let me try again...

it needs to know who sent it to be able to reply with an error

moparisthebest: howaboutno

no single server knows who sent it or who it is intended for

damnit

no single server knows BOTH who sent it AND who it is intended for

finally, need more coffee

moparisthebest, the destination server needs to know both

moparisthebest: then you have to filter spam at the client.

it needs to be able to deliver it to the client locally

and it needs to be able to reply with an erro

to the original sender

jonasw, right, to the original sender's SERVER

who then handles it from there

and how would that know where to send it?

that's encrypted so only the senders server can decrypt it

I see

Ge0rG, yep you always have to with e2e meh

moparisthebest, incorrect

whatsapp and others filter spam solely based on metadata

and here you have even less metadata

email spam is also filtered based on metadata to a large extent (DNSBLs for example)

which is in fact the entire point

yes, but that’s not a property of e2ee

you can still filter the DNSBL way, ie, blocking the whole server

but that's it

Zash, you don't want to implement it as a server dev or you think it won't work or you think it's a terrible idea, or all 3? :P

Insufficient context

I know I'm late to the party, but: <response thread="ban-opposing-sides"/>

threat!

Zash, I guess it’s 14:16:46 Zash> moparisthebest: howaboutno

yep

On phone, it scrolled out of view.

Anyone wanna add a in-reply-to equivalent thing to XMPP ?

Zash, there are three of that

Zash: References. You're welcome.

(1) Threads, (2) https://xmpp.org/extensions/xep-0372.html, (3) https://xmpp.org/extensions/xep-0131.html

possibly more

so the client would have to negotiate this with their server who would negotiate it with the remote server, then the client would triple encrypt everything before sending

Step two, bother client devs

Zash, no, step 2 is to find a proper UI for that

jonasw: I'd show you my irc client

Zash, how does that do In-Reply-To?

https://www.zash.se/upload/MdiT9Ke5RKyC07wpWTErEw.jpg

Long press on message

All it does afaik is to add the nick as a prefix

Zash, that only seems like a reasonable workflow on mobile :/

hm

desktop could have a button

What, isn't mobile first the thing anymore?

I don’t care about mobile :)

And desktop never

(a lot) ✏

>> I'm concerned that "No" is not semantically transmitted, and therefore may be interpreted differently in multiple clients. > dwd: I see that you're married. I need to stop reading Guus' comments on the bus, people look at you funny when you laugh loudly in public.

Maybe you can infer from nickname prefix

sorry what's this > business in front of your messages SamWhited ? I don't understand /sarcasm /no-need-to-respond :)

SamWhited, I learnt that the hard way while reading The Hitchhikers Guide to the Galaxy for the first time.

jonasw: ooh yah, I wouldn't mind reading that again, but maybe not on the bus.

“13:17:24 zinid> we don't have avatars working goddamit”, do you have any issue with XEP-0153 in a specific deployment?

I have an issue with XEP-0153 :/

it’s the whole damn thing :P

yeah i dont get that, xep-0153 covers all use cases in my opinion, i dont know why we every would need more

the only thing that can be said thats not so nice is, that you can request the avatar alone

lovetox, notification on change?

jonasw, it’s a thing which works, today, in every case.

and also have to request whole vcard

jonasw, presence update.

jonasw, presence?

oh

but avatar data will always way more then vcard data

so not that big of a problem

I didn’t know that

then you never read 0153

I admit that

I read the title and that it was historical and assumed it’d be polling the vcard

Long ago I wanted to add a vCard value for 0084 too, but I never followed on that.

Link Mauve: I have no problems with 0153, I have problems with 0153 and 0084 being implemented by different clients

Link Mauve: also 0084 doesn't work in mucs

and now we're doing the same weird shit with vcard-4

I heard nobody uses vcard-4?

jonasw: MIX suggests it for example

no though i plan to use it

jonasw I do, over PEP

works great

ok, we probably need to say good bye to vcards as well

so no avatars, no vcards, no private storage, no file sharing

that's where we are in 2017

and you are discussing how to transfer bold

amusing

zinid, I want to transfer italics, not bold!

yup

zinid I do agree, and bookmark is still broken and non-atomic :p

yes, bookmarks are broken as well because of incompatible implementations

hopefully we can settle all of this when multi-item private PEP lands ✏

We'll still have 2-3 XEPs for transmitting bold then :-)

jonasw PEP could be just Pubsub on JID <3

zinid, clients implementing 0084 instead of 0153, latest 0048 instead of previous 0048 which used to use 0049, because of some perceived superiority of PEP, are the stupid ones imo.

🦄

vCard 4 is also something which should be replaced with vCard.

Link Mauve: I think we are the stupid ones in failing to agree on a solution for a given problem.

First step would be acknowledging this as a problem, but I'm being told that's all just the usual XEP standardization process and there's nothing fundamentally wrong with it.

Link Mauve: should be replaced? like in https://xkcd.com/927 ?

I didn’t want to propose to deprecate 0084 or vCard 4 or 0223, mostly because in the future they could be better, but it seems best to ignore them currently.

Link Mauve what's the issue of using PEP for everything related to JID informations ? then we have one way of getting and setting those info

Holger ++

Holger, yes, I agree.

also with Prosody having persistance and Pubsub now we will be able to use PEP for mostly everything

edhelas, not really, no.

Link Mauve, excuse me, if I am faced with a choice between a Draft and a Historical XEP, I’m going to implement Draft.

edhelas: prosody isn't even there yet

0084 is still fundamentally broken, despite persistency in one specific implementation.

I learnt the hard way that XEP-0084 isn’t deployed widely, and I’m super-annoyed that I had to find out the hard way.

jonasw, yes, the state of these XEPs is sad.

Link Mauve why 0084 is broken ?

edhelas: it doesn't work in mucs

if it’s not supposed to be implemented, council should make sure that it doesn’t look like one should

ah yes MUC…

let's talk about vcards and avatars for Pubsub nodes as well

but I firmly reject to be the "stupid one" here.

edhelas, it’s only usable by your contacts, in your roster; if you’re in a MUC you can’t use it, if you’re just chatting with someone who isn’t in your roster you can’t use it.

basically what we are trying to do with MIX

jonasw, as Holger pointed it, it’s not users or developers who are the stupid ones, but the XSF and our current standardisation process.

XEP-0048 is even worse because you can’t easily discover that the whole way to store it was changed

allowing PEP for any nodes and JID would be nice

jonasw, yes.

Link Mauve, oh, I missed that :(

edhelas: but how? by obligating a user's server to keep MIX metadata?

for example a MUC admin can set a vcard node to his MUC

edhelas, you can already do that though.

I think that the XEP-0048 should be rolled back and a new XEP should be made at some point, because this was a massive change which shouldn’t happen in draft.

jonasw roled back to private-xml ?

edhelas, yes

hell no

not becaiuse of technical superiority, because it was incredibly wrong procses-wise

jonasw I'd like to manage bookmarks this way https://xmpp.org/extensions/xep-0330.html

I don’t think that private-xml is a good way to store things (but PEP isn’t there yet either, due to lack of deployment), but I don’t think that we can exchange a whole XEP in a minor revision in Draft state!

as I said, if PEP will be correctly implemented it would unlock many possibilities

even if avatars for mucs will not be solved…

Link Mauve what is missing in Prosody to have proper PEP support (persistance and pubsub stuff related) ?

last time I've checked it was getting there

edhelas, isn't it in trunk already? just the flag that's not turned on

well yeah

I have some minor issues with configure on create but it was fine overall (thanks again for the work btw)

I have to check again though

Maybe I can make that patch, I have never really looked into prosody's sources seriously. Turning on a flag shouldn't be that hard? (not right now though)

Different topic: The current MAM revision says the "server add an <stanza-id/> element" to live messages, and "SHOULD include the element as a child of the forwarded message when using Message Carbons". Why only SHOULD? Now the client can't rely on carbons being tagged. Wasn't the whole point of bumping the MAM namespace to make this guarantee?

what about having PEP for muc resources ? when I join a MUC I still advertise to the MUC service my caps, if I have avatar+notify the service can push me the avatars of the resources of the MUC (or vcards, or even tunes, geolocation…)

lol Holger, i definitly depend on that

So change this to a MUST and bump the namespace again? :-) mam:3 will be the one you can depend on, this time for real? :-)

madness

and naturally the messages containes <x> muc tags then I can differenciates vcards that are coming from resources

could work no ?

Morning

Its meeting time apparently , anyone else here?

arc, You're aware of TZ changes? I don't know what Board agreed WRT handling those.

1600utc this is the time

Indeed it is: https://calendar.google.com/calendar/embed?src=64v3vs15qlalgqv0j7r99ikm1c%40group.calendar.google.com

(I remember to have meticulously marked that in the calendar when the scheduling timezone thingy was discussed)

Iirc I copied guus's calendar entry to my own

OK. It *is* Council at this time too. Also Martin is off sick, so he shouldn't be attending.

What tz is council meeting at?

dwd: see calendar: you guys then agreed to do that in UTC too

Completely not up to me to change that, but please update the calendar if you do :)

are nonzas used in other places than CSI or defined someplace?

moparisthebest, there are quite a few nonzas in RFC 6120

(sasl, starttls, stream features, are there more?)

doesn't actually mention the term 'nonza' though, but yea

I still believe nonza isn't a helpful term :)

moparisthebest, https://xmpp.org/extensions/xep-0360.html

ha I like how that comes *after* CSI

moparisthebest, careful, the term nonza is another thing where the community can be split in two halves.

With most things you will find someone raising a voice against…

And of course having a well defined term for something we didn't have an unambiguously (short-)term before is very helpful

1. Nonzas MUST NOT be routed, i.e. they are only exchanged between the two endpoints of an XMPP stream. 2. Nonzas SHOULD NOT have a 'from' or 'to' attribute.

hmm, so what if one wanted to introduce a new nonza-like thing but that did get routed with specific routing rules?

that’s a something-za then

what would you call that, a rononza ?

ronza?

;-)

moparisthebest, I'm not sure if you could introduce such a thing even if the nonza xep didn't exist

frankly, with what you’re going for, I’d suggest inventing a new term, because neither nonza nor stanza is applicable

(while stanza being strictly defined in RFC 6120 IIRC)

moparisthebest: that would be against 6120, if I'm not mistaken

SamWhited, does RFC 6120 forbid routed elements wihch are not <iq/>, <message/> or <presence/>?

jonasw, not explicitly, but how is that supposed to work with federation?

Flow, moparisthebest plans some negotiation

Oh, I thought it did explicitly, but maybe not

Flow: Same as everything else, with negotiation.

yea it'd be opt-in

moparisthebest, what if the recipient is offline?

(it possibly would help if I knew what excactly you trying to achieve ;))

onion xmpp, minimum-metadata xmpp, not sure, naming is one of the hard problems

but even then, if you do negotiation anyway you could just use an IQ or an extension element, which you probably should do anyway because those things get SM ack'd

don't those have to have a from and to ?

I guess maybe you could still hack it in

no

<deliver to="otherserver.com">(this part is encrypted blob #1)<deliver to="jid@otherserver.com">(this part is encrypted blob #2)<message from="bob@bob.com" to="jid@otherserver.com">etc</message>(/end encrypted blob #2)</deliver>(/end encrypted blob #1)</deliver>

that's something like what I'm thinking

each server only knows the hops next to it, no single server knows which 2 clients are talking

Nice idea

hopefully in that way things like carbons/mam/offline/sm etc etc all work the same

moparisthebest, That's how Tor works, indeed. More or less.

moparisthebest, wrapping everything in <message/> addressed to the next hop would probably work

yea and from the one it can know probably

and would give you SM greatness

ack

(pun not intended)

<message to="otherserver.com">(this part is encrypted blob #1)<message to="jid@otherserver.com">(this part is encrypted blob #2)<message from="bob@bob.com" to="jid@otherserver.com">etc</message>(/end encrypted blob #2)</message>(/end encrypted blob #1)</message>

Where do you put the security label?

well you'd have to put those in a new tag inside message of course

but that's the general idea

that’ll be some nice overhead right there, base64 on every iteration :)

moparisthebest, I think the destination server should see the sender address

and I think you get the key for otherserver.com from DNS

well that's what you are trying to avoid Flow

you can possibly safely disguise the recipient from the senders server, but if the destination server doesn't know the sender address then it becomes easy to drain your mobiles battery

would also have an odd side-effect, today you run 1 server for you and all contacts to minimize servers with full metadata

this would only give you extra security with different servers

But that's a discussion from when the first wild ProtoXEP appears

*for

Flow, yea and probably the only solution is 'would you like to recieve onion messages from someone at otherserver.com'

mayben even not that, because that would also cause your mobile radio to power up

your server would only ask you once

or, once every X when it already had an active connection or whatever

that could work

hm, right, you can’t even filter by roster on the server side

board meeting?

except if you put some keys into the roster, too

nope no roster or precense or anything here

and you'd never want to send other stanzas to each other

moparisthebest, right

I don’t like that

I don’t see how you can have this in a sane manner.

it would involve a super extra level of opt-in :)

which doesn’t push all the validation load on the client

but also, precense isn't important anymore remember? :)

conversations doesn't display it normally, for instance, and with offline/mam etc all working, no one cares

moparisthebest, presence isn’t, but being able to filter messages by sender server-side is.

spam filtering essentially

yep you can only do by whole server this way

yes, which is bad

not really if it's opt-in

I frankly don’t see this finding a serious user base

nyco, doesn't look like board meeting :(

indeed

Arc was here an hour ago

yep

jonasw, when has that ever stopped a xep or code :)

Nyco we're on UTC

this changes the hour of availability

While daylight savings time is indeed daft, I don't think ignoring it is the solution - Council basically had to move because a UTC-pinned meeting ends up clashing for me (at least, every other week).

for me too

let's remove timezones already, one planet, one time

In the interest of making small, incremental changes let's remove DST first, then we can consider timezones.

Swatch Internet Time in Beats?

meanwhile we still have no board meeting...

ok, gotta go ;-)

nyco, As noted earlier, Martin's off sick so cannot (or rather should not) attend.

you’re not his mom!kk

jonasw, True, but I can get Laura to say the same.

(For the avoidance of doubt, Laura is not Martin's mum either)