SamWhiteddaniel: 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.
vanitasvitaeSamWhited: maybe because mine is a httpupload link?
vanitasvitaeAh, maybe thats not the reason...
SamWhitedyah, 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)
SamWhitedNot a big deal, it just "feels" inconsistent
danielSamWhited: 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
danielThe muc does reflect that
SamWhitedThat makes sense
Steve Killehas left
sezuanhas left
jjrhhas left
jjrhhas left
Tobiashas joined
vanitasvitaehas left
jjrhhas left
danielhas left
Tobiashas joined
jjrhhas left
zinidhas left
jjrhhas left
jjrhhas left
Tobiashas joined
Arcwell one's http vs https
Arcis the mime being sent on each?
Valerianhas left
Tobiashas joined
danielhas left
jjrhhas left
Valerianhas joined
jjrhhas left
danielhas left
Valerianhas left
Valerianhas joined
la|r|mahas left
Valerianhas left
Valerianhas joined
jjrhhas left
jjrhhas left
efrithas joined
jjrhhas left
jjrhhas left
Tobiashas joined
danielhas left
danielhas joined
danielhas left
la|r|mahas joined
danielhas joined
lskdjfhas joined
@Alacerhas left
@Alacerhas joined
efrithas joined
nycohas joined
edhelashas joined
danielhas left
danielhas joined
jerehas left
sonnyhas left
sonnyhas joined
danielhas left
danielhas joined
danielhas left
jerehas joined
danielhas joined
Zashmoparisthebest: 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.
Valerianhas left
Valerianhas joined
Valerianhas left
Valerianhas joined
Valerianhas left
Bunnehhas left
Bunnehhas joined
Valerianhas joined
Bunnehhas left
Bunnehhas joined
Valerianhas left
Bunnehhas left
Bunnehhas joined
Bunnehhas left
Bunnehhas joined
danielhas left
danielhas joined
SamWhitedhas left
uchas left
uchas joined
Bunnehhas left
Bunnehhas joined
Bunnehhas left
Bunnehhas joined
Bunnehhas left
Bunnehhas joined
Bunnehhas left
Bunnehhas joined
Bunnehhas left
Bunnehhas joined
Guushas left
Guushas joined
Bunnehhas left
danielhas left
danielhas joined
Bunnehhas left
Bunnehhas left
Bunnehhas left
Bunnehhas left
Bunnehhas left
Bunnehhas joined
danielhas left
danielhas joined
lumihas joined
Guushas left
Guushas joined
danielhas left
danielhas joined
Ge0rGhas left
danielhas left
danielhas joined
goffihas joined
@Alacerhas left
@Alacerhas joined
Ge0rGhas left
danielhas left
danielhas joined
danielhas left
danielhas joined
archas left
archas joined
Ge0rGhas joined
edhelashas joined
nycohas joined
Ge0rGhas left
Archas left
nycohas joined
edhelashas joined
Ge0rGhas left
Guushas left
Guushas joined
Guushas left
Guushas joined
edhelashas joined
danielhas left
danielhas joined
ralphmhas left
nycohas joined
SamWhitedhas left
danielhas left
danielhas joined
Ge0rGHow does the OOB tag interop with OMEMO? It's obviously leaking data, but what exactly? Is the password only contained in the body?
ZashI am under the impression that it's just a special URL in the (encrypted) body, with the encryption key in the #this part.
zinidleaking data my ass...
zinidyet another round of bikeshedding
Bunnehhas left
Bunnehhas joined
Ge0rGZash: yes, that's how it works. But what is contained in the oob tag?
danielhas left
danielhas joined
Ge0rGI would look up myself, but I don't have any OMEMOs
ZashI don't believe there is one
nycohas left
nycohas joined
goffihas left
Ge0rGZash: I was under the impression that Conversations needs the oob tag to display inline images
Ge0rGhas left
danielhas left
danielhas joined
goffihas joined
archas left
nycohas left
archas joined
danielhas left
nycohas joined
jonaswGe0rG: oob is safe enough for daniel, sims would not be: https://github.com/siacs/Conversations/issues/2637
Ge0rGI'd probably consider the picture URL and file size to be private as well, but what do I know
ZashWhere's that blag that said that e2e crypto is basically just marketing fluff?
intosihas joined
Ge0rGHm. of all people, I should know that.
danielhas joined
@Alacerhas left
@Alacerhas joined
jcbrandhas joined
danielhas left
Steve Killehas left
danielhas joined
Steve Killehas left
Steve Killehas left
Tobiashas joined
danielhas left
danielhas joined
Tobiashas joined
xnyhpshas joined
danielhas left
danielhas joined
Steve Killehas joined
jonaswSamWhited, 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)
jonaswdaniel, 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)
jcbrandhas left
jonaswbut hey, we already agree on the input format, I think that’s really nice, and it’s nice to have that standardised.
Ge0rGI only wish for a way to skip formatting when typing formulas
jonaswor any other content for that matter.
jonaswor any other content which shouldn’t be formatted for that matter.
jonaswbut nobody listens to me
ZashIt seems weird to me to be XEPing what amounts to UI things
Ge0rGZash: because you are a server dev
Ge0rGZash: I care very much about UI things, and I want them consistent across implementations
FlowI'm sure everybody already noticed that XHTML-IM/styling/markdown/bmh discussion related thing on HN: https://news.ycombinator.com/item?id=15646425
Ge0rGThis is the major weakness of XMPP. Every client works differently
ZashBut sometimes it is a strength.
jonaswdepends
jonaswI think for each major workflow we’d need a set of clients covering each platform.
ZashAltho according to some random Reddit thread I saw, none of the competition things work as they should in FOSS
jonaswcurrently, conversations covers the "non-technical" workflow pretty well on mobile.
Ge0rGZash: yes, if you believe that you need the opportunity to differentiate on quality of implementation.
ZashWell, optimally the differentiation would be on proirites, so you could find a thing that sucks in ways you don't care about.
Flowjonasw, 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?
jonaswFlow, I looked at References
jonaswit would be a major (size) overhead to have a <reference xmlns="…"> element for each bit of markup though
Flowjonasw, not reference
Flow<bodytext/>
Flow(see linked mail)
Steve Killehas left
FlowUh wait, maybe I misunderstood Dave's mail, he was probably just talking about factoring the data into an extra element
Flownot using that as generic element which can be re-used by other xeps
Flowtrue, but the idea is appealing. such an generic element could also specify how it's used with non-<body/> body text
Flowlike the text found in OMEMO messages
Kevhas joined
jonaswI 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/>.
la|r|mahas joined
jcbrandhas joined
jonaswbut there are different issues with combining this with OMEMO which need to be discussed in the security considerations (OMEMO won’t encrypt the markup...)
Flowjonasw, i fear it's a bit more complicated than that
jonasw(nor will it authenticate the markup, which is bad too)
jonaswFlow, is it?
ralphmhas left
Flow1. 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)
jonaswmultiple unencrypted body elements must have xml:lang tags to distinguish them, as do <markup/> elements.
jonaswI presume that this is the same for OX?
Flowyep
ZashWhat does happen if you have multiple bodies with e2e?
Flowbut I possibly place the xml:lang selector not in <markup/> but in the generic <bodytext/>
FlowZash, what happens if you have multiple bodies without e2e?
jonaswFlow, that makes things more complex to parse and generate I think
ZashI haven't a clue
jonaswFlow, I think e2ee simply doesn’t allow that
jonaswit’s also not a very common use-case in IM
FlowOX does not forbit multiple <body/> elements
Flow*forbid
jonasw*currently deployed e2ee simply doesn’t allow that ;-)
danielIs there an OX implementation in smack Flow?
Flowdaniel, there is a branch a started a while ago
Flowbut nothing even prototypical
Flowyet
pep.jonasw: maybe you should cover the case in markups. How does it work when there are multiple bodies ATM? (Different xml:lang)
Flowfirst ISR, then OX. that is the current order of my priorities ;)
jonaswpep., it’s in the Business rules and the Internationalisation considerations.
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
pep.jonasw: also, unrelated, I'm not really fan of leaving the list/quotation characters etc., in the rendered version
jonaswpep., I agree
jonaswit’s tricky to avoid though
jonaswI’m writing a response to standards@ about this
pep.K
jonasw(Goffi brought it up there)
pep.Will read
pep.And I need to reply as well
jonaswpep., there you go
danieljonasw: aren't the > and * you use in your example kinda like markup information in the body?
danielWhich the xep says you are trying to avoid?
danielhas left
pep.That's why I don't like them
dwddaniel, It's only bad if someone else does it.
jonaswdaniel, it’s not required for them to be there at all.
jonaswthey don’t carry any meaning.
lskdjfhas joined
jonaswhowever, if combined with Message Styling, I can totally see letting them in there for compatibility.
pep.What's the point if you already have the meaning of your markup translated
dwdpep., Fallback.
jonaswyou can’t stop people from typing them (I do too!), and I’m totally in favour of specifying the input format Message Styling defines
Ge0rGAnd 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.
jonaswbut in contrast to the Message Styling wire format, we could adapt to changing behaviours and trends in the meta-characters used by humans
jonaswwhich is nice
jonasw(I mean, adapt without breaking old archives and interop for the transition period)
pep.jonasw: leaving it there defeats the point of not putting markup on the body
jonaswpep., tend to agree.
jonaswbut some kind of fallback is needed.
pep.Why?
jonaswespecially for quotations
jonasw(not so much for lists)
KevMy 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*.
jonaswif a client doesn’t understand <markup/>, it would render the quotations as normal paragraphs.
pep.Do we have a failback for every single xep out there? In case the first one isn't supported
jonaswpep., I think most XEPs either specify a fallback or fail gracefully.
KevAnd so just documenting roughly what people are already typing in messages is both pragmatic and sensible.
Kev(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)
jonaswKev, my main problem with Message Styling isn’t that it does that, but that it doesn’t have an opt-in.
Syndacehas left
Ge0rGKev: actually, all clients support rendering it... as ASCII
pep.Ge0rG: agreed
KevGe0rG: Potato potato :)
danielhas left
jonaswif we’re going to change the rendering with possibly removing charatcers (e.g. for quotations!), then it must be opt-in.
KevWe should not be removing characters.
jonaswand I think that it should still be opt-in even if those characters are preserved.
danieljonasw, isn't opt-in something your client should support?
jonaswdaniel, no, because the client can’t know if the sender intended it.
KevWe should be rendering the existing characters with additional styling, or should have a local toggle.
Ge0rGKev: but it's up to the sender to decide whether they want markup for a given ASCII sequence.
Kev(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)
danieli'm not really sure what you mean by opt-in then
jonaswdaniel, an additional element to <message/> which indicates that the body can be interpreted according to the Message Styling rules.
Ge0rGI think that when copy&pasting things from the IM client, the original body should be copied with all "markup" characters present as-is
Ge0rGjonasw: that would be body-markup-hints?
danieljonasw, i can get on board with that
jonaswGe0rG, exactly.
jonaswdaniel, I said so on the list, nobody cared :(
Ge0rGthe sending client could pre-render markup in the input field and offer a button to strip markup
Ge0rGso you can paste code.
Ge0rGbut then interop.
mimi89999has joined
Ge0rGYou can't fix Gajim overnight
jonaswGe0rG, lovetox can :)
Ge0rGSo we need two hints. One for "this is markup" and another for "this is definitively not markup"
danieli'm not really sure I want Flows xep for that though. because then styling would depend on Flows xep getting accepted
jonaswdaniel, I think flows xep was rejected anyways?
Zashhas left
KevGe0rG: Isn't this similar to the "I meant what I sent" that I was talking about with not doing emoticon rendering?
dwddaniel, It needs something like Flow's BMH. Not *exactly* it.
jonaswdwd, I think in fact it pretty much needs that.
Kev(Although not quite the same)
Ge0rGKev: I thought you were talking about the receiving side
Ge0rGI'm still annoyed by some IM clients replacing (b) and (y) with random emoji.
jonaswdaniel, in fact, my arguments for opt-in were dismissed with something along the lines of "edge cases nobody should care about".
jonaswGe0rG, kill trillian with fire
Ge0rGjonasw: also, Gajim.
danieljonasw, i'm trying to find your email in that huge bike shadding thread to give a thumbs up
jonaswDate: Yesterday 19:29
jonasw(CET)
jonaswif that helps
Zashdestroyallsoftware?
danielit does
Ge0rGKev: "I meant what I sent" could be a BMH of "text/plain"
dwdGe0rG, I don't think we need the complexity of media typing here, actually.
Ge0rGdwd: right, let's just invent a new name for it.
dwdGe0rG, Would you want text/html there?
jonaswI get shivers.
jonaswalso, note that BMH is not Content types
dwdGe0rG, If anything, we want a media type of: `text/plain; format=XYZ`, with ZYX given by a BMH-a-like.
Ge0rGOkay, BMH only relates to body, so "text/" is implicitly pre-set.
Ge0rGI don't like the use of the term "Language" in there.
Ge0rG</bikeshed>
dwdGe0rG, Yes, excellent point, this is veyr much a bikeshed.
danielhas left
jonaswBMH essentially foresaw Styling.
jonasw> TODO: Shall we define your own subset of e.g. CommonMark, XMPPMark? :)
jonasw(or shall I say, inspired?)
dwdI think the writing was on the wall.
Ge0rGdwd: as opposed to the exact BMH identifier string to be used for "this is not markup"?
dwdOnly we couldn't parse it properly because it turned out nobody knew what *this* meant.
Ge0rGI still want code syntax highlighting.
dwdGe0rG, I'm not worried about clients heuristically doing that in ```these sections```.
danielhas left
ZashWhat about `if(what){then()}`{.c}
Ge0rGlike heuristically rendering /italics/ and *bold*?
Ge0rGZash: I think it's sensible to keep syntax coloring to ``` blocks, not to `spans`
danielhas left
Ge0rGSo 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
dwdGe0rG, I think that's sensible. I'm not entirely sure about the middle case, but I don't care enough to object.
danielgajims current rendering is pretty annoying btw
jonaswdaniel, didit boldface everything between (*) and (*)?
danielyes
jonaswkill it with fire
dwdjonasw, Yup. Not a huge fan of that, nor leaving the *asterisks* in place.
dwdjonasw, But as a heuristic solution it's OK, and 99% of the time gets things right.
jonaswGe0rG, 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.
Ge0rGx * y - z * 3
zinideasy to writer a parser they said
jonaswGe0rG, and I don’t think that’s an assumption an client operated by a human can reasonably have
dwdjonasw, Ge0rG literally just outlined a way to communicate exactly that.
Ge0rGjonasw: the sender needs to pre-render the markup in the input line of course.
danielzinid, the styling xep has a very straight forward parser
jonaswdwd, sender as in the human operating the client, not as in the program
danielit's just about defining the rules properly
jonaswGe0rG, that’s a very complex thing not many clients will do.
Guushas left
Ge0rGjonasw: an easier thing would be to have a button on the sent message to "remove markup", which would send an LMC with a BMH.
ziniddaniel: can I use LALR(1) parser? if not, it's not simple
jonaswGe0rG, sounds like a plan!
jonaswdidn’t think of LMC in this context, kudos
jonaswzinid, I think LALR(1) should do
zinidjonasw: can I have grammar.y then? or should I write it manually because it's funny?
jonaswzinid, I suggest that the XEP authors provide a formal definition of the grammer once it is accepted :)
zinidjonasw: ok
Ge0rGBNF FTW!
zinidABNF would be awesome, I could use ragel
jonaswABNF seems very reasonable considering that it’s the IETFs go-to representation for grammars.
danielGe0rG, if we want to annotate i'd prefer the simpler 'opt-in' proposal jonasw had
ZashNot EBNF?
jonaswZash, I always forget the exact acronym
@Alacerhas left
danielyou could still to 'send lmc to remove style'
Ge0rGdaniel: the simpler opt-in mechanism requires all clients to update
Ge0rGdaniel: ah, LMC-based markup removal. Yeah.
Zashjonasw: Looks like both ABNF and EBNF exist
jonaswdaniel, 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.
archas left
archas joined
danielGe0rG, most clients need to update anyway. because gajim doesn't support styling for example
jonaswBMH 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.
jonaswGe0rG, re code blocks, by the way, a common convention is "```language\n<code here>\n```"
jonaswthat’s how gitlab markup does it
Ge0rGjonasw: yeah, I could live with that.
ZashThat's how pandoc does it.
@Alacerhas joined
mimi89999has left
Guushas left
Ge0rGre "text/plain", Tobias wrote re BMH: "I wonder whether it makes sense to reuse IANA Media Types instead of starting a new registry."
valohas left
jonaswGe0rG, at which point it would’ve been Content Types (<https://xmpp.org/extensions/inbox/content-types.html>) which was rejected over a year ago
Ge0rGHistory is repeating.
Ge0rGCan't we just change the message type? (I mean the 'type' attribute of the <message> stanza)
jonaswGe0rG, go away.
jonasw;-)
TobiasGe0rG, i think the RFC doesn't allow additional parameters on that
Tobiasor additional attributes on body
jonaswnamespaced attributes! (Sam is gonna shoot me)
Ge0rGTobias: we can override the RFC with an XEP. I'm sure nobody will notice.
Zashjonasw: y u do this
jonaswZash, what?
Zashjonasw: mention namespaced attributes :)
jonaswI think they’re great.
Ge0rGdo they need namespace versioning as well?
jonaswsure
jonaswI 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.
jonaswor rather have useful plaintext fallbacks right from the beginning
jerehas joined
nycohas left
la|r|mahas left
nycohas joined
Kevhas left
Kevhas joined
zinidhas left
lskdjfhas joined
danielhas left
KevWell, also whether you want what people already type to be correctly handled everywhere.
jubalhhas joined
jonaswKev, no, that’s input conventions and should not matter for wire formats.
KevAssuming universal adoption.
KevBut this 'just render what's sent with styling enhancement' has been in use for a very long time without issue.
jonaswif 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.
jonasw(mostly because XML can’t carry those, but also because it’s not a useful plaintext fallback)
ZashI like arguments like "everyone is already doing it" and "has worked forever without issue"
jonaswKev, I doubt you can say "without issue" just 50 lines after somebody complained about how broken gajim handles that.
ZashEspecially when people are pointing out the times it's messy and doesn't work
mathieuijonasw, which is why I’ll wirte a protoxep in order to send the poezio internal format over the wire, escaped
mathieuijonasw, which is why I’ll write a protoxep in order to send the poezio internal format over the wire, escaped
Kevjonasw: Gajim may do something stupid, but Psi doesn't.
nycohas left
KevI'm not saying that doing other things than what I'm suggesting works without issue :)
jonaswKev, but it kind-of moots the "everyone is doing it and it works great" point
mathieui"psi is doing it, and for some cases it works great" already doesn’t sound that good
KevIt would certainly bring into question that point that I'm not making, yes.
@Alacerhas left
KevA lot of people are sending this stuff on the wire, irrespective of rendering. Some clients (at least Psi) also add styling successfully to it.
nycohas joined
jerehas joined
jonaswKev, "without issue" is certainly wrong, but I’m not going to nitpick here (and I probably misread some statement)
KevWhat's the issue with what Psi's doing?
jonaswI don’t know psi, but what gajim does is certanily an issue.
jonaswso it’s not without issue at all.
KevIt basically just turns *thing* into <b>*thing*</b>
mathieuijonasw, Kev’s point is that it has been in use for a long time without issue, in psi
mathieuiwhich is not contradicted by "gajim handles things wrong"
KevI 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".
Steve Killehas left
jonaswKev, maybe I missed what you indeed suggest :)
danielhas left
danielhas joined
mathieui(I haven’t used psi in a very long time so I can’t argue with that)
KevJust adding styling to ** // __.
jonaswKev, well gajim does exactly that
Kev(Without removing the characters)
KevIf Gajim does exactly that, what's the issue?
jonaswit also does that across newlines
mathieuijonasw, gajim has somewhat looser boundaries
mathieuiI think psi only does it for words
jonaswmathieui, Kev didn’t say anything about boundaries :-)
mathieuie.g. the formating chars are stuck to the words
@Alacerhas joined
goffiKev: 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?
Steve Killehas joined
KevI forget, I wrote this a decade and a half ago or so.
mathieuijonasw, 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
KevI'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.
KevBut 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.
KevBut ISTR I made Psi not do word partials.
jonaswFTR, 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)
valohas joined
KevThere *is* a definite advantage to having this out of band, BTW, which is that you can not annotate things that are pastes.
KevBut I think you can achieve the same thing just by having <paste/> as a child.
KevAFK a while.
Kevhas left
Kevhas joined
Kevhas left
jerehas left
jerehas joined
intosihas left
Guushas left
Alexhas joined
Ge0rGhas left
Alexhas left
Alexhas joined
Kevhas joined
Guushas left
Guushas left
ralphmhas left
Syndacehas left
ralphmhas left
Flowhas left
Flowhas joined
lumihas joined
danielhas left
jubalhhas left
danielhas left
Alexhas left
la|r|mahas left
intosihas joined
la|r|mahas joined
jonaswhas left
danielhas left
jerehas joined
jerehas joined
la|r|mahas joined
la|r|mahas joined
danielhas left
jonaswhas left
@Alacerhas left
@Alacerhas joined
Valerianhas joined
jubalhhas left
Alexhas joined
danielhas left
brahas left
moparisthebestI 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"
Zash/thread
jonaswitym </thread>?
zinid*thread*
Ge0rG*italics*
mathieuii*italics*
intosi["The last word should be ", {"style": "bold", "contents": "bold"}]
dwdI'm concerned that "No" is not semantically transmitted, and therefore may be interpreted differently in multiple clients.
Guusdwd: I see that you're married.
dwdWe 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.
dwdGe0rG, And from there, but a short step to eliding the communication entirely, making XMPP so much more bandwidth efficient.
intosiI would propose BER, but I'm too lazy to do so.
ZashB2B communication
dwdintosi, PER, surely, or does David no longer get excited by that one?
Zashintosi: have you considered beer instead
Ge0rGdwd: that's absolutely the wrong direction. We can finally increase XMPP's popularity by populating the network with m2m semantics-capable clients
intosiZash: +1
intosidwd: I am not presently in the same room as David, he cannot complain.
dwd<ironic-statement/>
Ge0rG<sarcastic-retort/>
dwd<assertion-of-fascism/>
jonasw<godwins-law/>
Zash<statement:nonsensical rel='plankton'/>
moparisthebestI'm super sorry to turn the topic of conversation here, but, Zash about layers of encryption so each server only knew bare minimum
moparisthebestseems like it could still be XMPP but we'd just have to wrap things in new nonzas ?
jonaswmoparisthebest, broadcast
zinid"We can finally increase XMPP's popularity" - this will never happen
moparisthebest<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>
jonaswmoparisthebest, what about presence broadcast, MUC?
moparisthebestjonasw, not sure, maybe it only works for messaging
jonaswMUC and MIX broadcasts?
Ge0rGjonasw: encrypted to the MUC service
Ge0rGjonasw: or multi-key-encrypted to all participants
moparisthebestit might only be feasible for bare-minimum metadata for direct chats
moparisthebestyea that'd work I guess, let the MUC service broadcast, idk
moparisthebestjust trying to throw crazy ideas out there that solve the metadata problem as much as possible
jonaswI don’t think that there is a real metadata problem.
moparisthebestwe are OK with specs that require changes on all clients and servers to be useable already, see MIX
jonaswor maybe there is, but I don’t think it’s reasonable to solve that within XMPP.
moparisthebestmight as well solve the metadata problem the same way
Ge0rGmoparisthebest: the best solution to the metadata problem is to run your own server for you and all of your important contacts
SamWhitedjonasw: 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)
moparisthebestdoesn't *solve* it, you still have 1 central service that knows everything
zinidmoparisthebest: solve what?
Ge0rGmoparisthebest: federated systems will always have metadata leakage. What you want instead is a P2P DHT chat system.
jonaswSamWhited, okay
moparisthebestmetadata problem
Ge0rGmoparisthebest: or maybe you want to connect to XMPP via TOR.
moparisthebestif I wanted that I'd just use tox, and have to change my phone battery every 20 minutes
moparisthebestI'm just talking about leaking bare minimum metadata to XMPP servers, the bare minimum for federated chat
Ge0rGmoparisthebest: so what you want instead is a tox agent running on a trusted server that you connect to.
moparisthebestthen you are back to 1 central server with all info
Ge0rGmoparisthebest: yes.
moparisthebestso you've got A (client) -> B (server) -> C (server) -> D (client)
Ge0rGmoparisthebest: with XMPP, you could hide the usernames of the people you talk to from your server. But not presence.
moparisthebestan ideal scenario has each only knowing about the next hop
Ge0rGmoparisthebest: and then still, the receiving server would know your full JID.
moparisthebestno they'd only know the server it came from, and who it's going to, not sending JID though
jonaswmoparisthebest, that doesn’t buy you a lot, you’d need to go full Tor essentially
moparisthebestI think it does buy you a lot
moparisthebestno server knows who sent it or who it's intended for
moparisthebestand that's the win you are looking for
moparisthebestworded that wrong, let me try again...
jonaswit needs to know who sent it to be able to reply with an error
Zashmoparisthebest: howaboutno
moparisthebestno single server knows who sent it or who it is intended for
moparisthebestdamnit
moparisthebestno single server knows BOTH who sent it AND who it is intended for
moparisthebestfinally, need more coffee
jonaswmoparisthebest, the destination server needs to know both
Ge0rGmoparisthebest: then you have to filter spam at the client.
jonaswit needs to be able to deliver it to the client locally
jonaswand it needs to be able to reply with an erro
jonaswto the original sender
moparisthebestjonasw, right, to the original sender's SERVER
moparisthebestwho then handles it from there
jonaswand how would that know where to send it?
moparisthebestthat's encrypted so only the senders server can decrypt it
jonaswI see
moparisthebestGe0rG, yep you always have to with e2e meh
jonaswmoparisthebest, incorrect
jonaswwhatsapp and others filter spam solely based on metadata
moparisthebestand here you have even less metadata
jonaswemail spam is also filtered based on metadata to a large extent (DNSBLs for example)
moparisthebestwhich is in fact the entire point
jonaswyes, but that’s not a property of e2ee
moparisthebestyou can still filter the DNSBL way, ie, blocking the whole server
moparisthebestbut that's it
moparisthebestZash, 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
waqashas joined
ZashInsufficient context
GuusI know I'm late to the party, but: <response thread="ban-opposing-sides"/>
Guusthreat!
jonaswZash, I guess it’s 14:16:46 Zash> moparisthebest: howaboutno
moparisthebestyep
ZashOn phone, it scrolled out of view.
ZashAnyone wanna add a in-reply-to equivalent thing to XMPP ?
moparisthebestso 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
ZashStep two, bother client devs
jonaswZash, no, step 2 is to find a proper UI for that
ZashAll it does afaik is to add the nick as a prefix
jonaswZash, that only seems like a reasonable workflow on mobile :/
jonaswhm
jonaswdesktop could have a button
ZashWhat, isn't mobile first the thing anymore?
jonaswI don’t care about mobile :)
jonasw(a lotr
ZashAnd desktop never
jonasw(a lot)
SamWhited>> 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.
ZashMaybe you can infer from nickname prefix
moparisthebestsorry what's this > business in front of your messages SamWhited ? I don't understand /sarcasm /no-need-to-respond :)
jonaswSamWhited, I learnt that the hard way while reading The Hitchhikers Guide to the Galaxy for the first time.
Guustips hat.
SamWhitedjonasw: ooh yah, I wouldn't mind reading that again, but maybe not on the bus.
lskdjfhas joined
Ge0rGhas left
georghas joined
Valerianhas left
lovetoxhas joined
Valerianhas joined
mimi89999has left
Link Mauve“13:17:24 zinid> we don't have avatars working goddamit”, do you have any issue with XEP-0153 in a specific deployment?
jonaswI have an issue with XEP-0153 :/
jonaswit’s the whole damn thing :P
lovetoxyeah i dont get that, xep-0153 covers all use cases in my opinion, i dont know why we every would need more
lovetoxthe only thing that can be said thats not so nice is, that you can request the avatar alone
jonaswlovetox, notification on change?
Link Mauvejonasw, it’s a thing which works, today, in every case.
lovetoxand also have to request whole vcard
Link Mauvejonasw, presence update.
lovetoxjonasw, presence?
jonaswoh
lovetoxbut avatar data will always way more then vcard data
lovetoxso not that big of a problem
jonaswI didn’t know that
lovetoxthen you never read 0153
jonaswI admit that
jonaswI read the title and that it was historical and assumed it’d be polling the vcard
Link MauveLong ago I wanted to add a vCard value for 0084 too, but I never followed on that.
nycohas left
zinidLink Mauve: I have no problems with 0153, I have problems with 0153 and 0084 being implemented by different clients
zinidLink Mauve: also 0084 doesn't work in mucs
zinidand now we're doing the same weird shit with vcard-4
jonaswI heard nobody uses vcard-4?
zinidjonasw: MIX suggests it for example
lovetoxno though i plan to use it
edhelasjonasw I do, over PEP
edhelasworks great
lskdjfhas joined
nycohas joined
zinidok, we probably need to say good bye to vcards as well
zinidso no avatars, no vcards, no private storage, no file sharing
zinidthat's where we are in 2017
lumihas left
zinidand you are discussing how to transfer bold
zinidamusing
mathieuizinid, I want to transfer italics, not bold!
edhelasyup
edhelaszinid I do agree, and bookmark is still broken and non-atomic :p
zinidyes, bookmarks are broken as well because of incompatible implementations
jonaswhopefully we can settle all of this if multi-item PEP lands
jonaswhopefully we can settle all of this when multi-item PEP lands
jonaswhopefully we can settle all of this when multi-item private PEP lands
HolgerWe'll still have 2-3 XEPs for transmitting bold then :-)
edhelasjonasw PEP could be just Pubsub on JID <3
Link Mauvezinid, 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.
edhelas🦄
Link MauvevCard 4 is also something which should be replaced with vCard.
HolgerLink Mauve: I think we are the stupid ones in failing to agree on a solution for a given problem.
HolgerFirst 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.
zinidLink Mauve: should be replaced? like in https://xkcd.com/927 ?
Link MauveI 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.
edhelasLink 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
SamWhitedHolger ++
Link MauveHolger, yes, I agree.
edhelasalso with Prosody having persistance and Pubsub now we will be able to use PEP for mostly everything
Link Mauveedhelas, not really, no.
jonaswLink Mauve, excuse me, if I am faced with a choice between a Draft and a Historical XEP, I’m going to implement Draft.
Ge0rGedhelas: prosody isn't even there yet
Link Mauve0084 is still fundamentally broken, despite persistency in one specific implementation.
jonaswI 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.
Link Mauvejonasw, yes, the state of these XEPs is sad.
edhelasLink Mauve why 0084 is broken ?
georghas left
zinidedhelas: it doesn't work in mucs
jonaswif it’s not supposed to be implemented, council should make sure that it doesn’t look like one should
edhelasah yes MUC…
edhelaslet's talk about vcards and avatars for Pubsub nodes as well
jonaswbut I firmly reject to be the "stupid one" here.
Link Mauveedhelas, 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.
edhelasbasically what we are trying to do with MIX
Link Mauvejonasw, as Holger pointed it, it’s not users or developers who are the stupid ones, but the XSF and our current standardisation process.
jonaswXEP-0048 is even worse because you can’t easily discover that the whole way to store it was changed
edhelasallowing PEP for any nodes and JID would be nice
Link Mauvejonasw, yes.
jonaswLink Mauve, oh, I missed that :(
zinidedhelas: but how? by obligating a user's server to keep MIX metadata?
edhelasfor example a MUC admin can set a vcard node to his MUC
Link Mauveedhelas, you can already do that though.
jonaswI 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.
edhelasjonasw roled back to private-xml ?
jonaswedhelas, yes
edhelashell no
jonaswnot becaiuse of technical superiority, because it was incredibly wrong procses-wise
edhelasjonasw I'd like to manage bookmarks this way https://xmpp.org/extensions/xep-0330.html
jonaswI 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!
edhelasas I said, if PEP will be correctly implemented it would unlock many possibilities
edhelaseven if avatars for mucs will not be solved…
edhelasLink Mauve what is missing in Prosody to have proper PEP support (persistance and pubsub stuff related) ?
edhelaslast time I've checked it was getting there
pep.edhelas, isn't it in trunk already? just the flag that's not turned on
edhelaswell yeah
edhelasI have some minor issues with configure on create but it was fine overall (thanks again for the work btw)
edhelasI have to check again though
pep.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)
HolgerDifferent 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?
lskdjfhas joined
edhelaswhat 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…)
lovetoxlol Holger, i definitly depend on that
HolgerSo change this to a MUST and bump the namespace again? :-) mam:3 will be the one you can depend on, this time for real? :-)
lovetoxmadness
edhelasand naturally the messages containes <x> muc tags then I can differenciates vcards that are coming from resources
danielhas left
Guushas left
edhelascould work no ?
waqashas left
danielhas left
arcMorning
arcIts meeting time apparently , anyone else here?
dwdarc, You're aware of TZ changes? I don't know what Board agreed WRT handling those.
arc1600utc this is the time
GuusIndeed it is: https://calendar.google.com/calendar/embed?src=64v3vs15qlalgqv0j7r99ikm1c%40group.calendar.google.com
Steve Killehas left
Guus(I remember to have meticulously marked that in the calendar when the scheduling timezone thingy was discussed)
arcIirc I copied guus's calendar entry to my own
dwdOK. It *is* Council at this time too. Also Martin is off sick, so he shouldn't be attending.
arcWhat tz is council meeting at?
jjrhhas left
Guusdwd: see calendar: you guys then agreed to do that in UTC too
GuusCompletely not up to me to change that, but please update the calendar if you do :)
danielhas left
Valerianhas left
jerehas joined
danielhas left
nycohas left
intosihas left
moparisthebestare nonzas used in other places than CSI or defined someplace?
jonaswmoparisthebest, there are quite a few nonzas in RFC 6120
jonasw(sasl, starttls, stream features, are there more?)
moparisthebestdoesn't actually mention the term 'nonza' though, but yea
moparisthebestha I like how that comes *after* CSI
lumihas joined
Steve Killehas joined
jonaswmoparisthebest, careful, the term nonza is another thing where the community can be split in two halves.
danielhas left
lovetoxhas left
FlowWith most things you will find someone raising a voice against…
FlowAnd of course having a well defined term for something we didn't have an unambiguously (short-)term before is very helpful
moparisthebest1. 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.
moparisthebesthmm, so what if one wanted to introduce a new nonza-like thing but that did get routed with specific routing rules?
danielhas left
jonaswthat’s a something-za then
moparisthebestwhat would you call that, a rononza ?
jonaswronza?
jonasw;-)
Flowmoparisthebest, I'm not sure if you could introduce such a thing even if the nonza xep didn't exist
jonaswfrankly, with what you’re going for, I’d suggest inventing a new term, because neither nonza nor stanza is applicable
jonasw(while stanza being strictly defined in RFC 6120 IIRC)
SamWhitedmoparisthebest: that would be against 6120, if I'm not mistaken
jonaswSamWhited, does RFC 6120 forbid routed elements wihch are not <iq/>, <message/> or <presence/>?
Flowjonasw, not explicitly, but how is that supposed to work with federation?
jonaswFlow, moparisthebest plans some negotiation
SamWhitedOh, I thought it did explicitly, but maybe not
KevFlow: Same as everything else, with negotiation.
moparisthebestyea it'd be opt-in
Flowmoparisthebest, what if the recipient is offline?
Flow(it possibly would help if I knew what excactly you trying to achieve ;))
moparisthebestonion xmpp, minimum-metadata xmpp, not sure, naming is one of the hard problems
Flowbut 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
moparisthebestdon't those have to have a from and to ?
moparisthebestI guess maybe you could still hack it in
Flowno
moparisthebest<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>
moparisthebestthat's something like what I'm thinking
moparisthebesteach server only knows the hops next to it, no single server knows which 2 clients are talking
jjrhhas left
FlowNice idea
moparisthebesthopefully in that way things like carbons/mam/offline/sm etc etc all work the same
dwdmoparisthebest, That's how Tor works, indeed. More or less.
jonaswmoparisthebest, wrapping everything in <message/> addressed to the next hop would probably work
moparisthebestyea and from the one it can know probably
marchas left
Flowand would give you SM greatness
danielhas left
jonaswack
jonasw(pun not intended)
Guushas left
Valerianhas joined
moparisthebest<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>
dwdWhere do you put the security label?
jcbrandhas left
moparisthebestwell you'd have to put those in a new tag inside message of course
moparisthebestbut that's the general idea
jonaswthat’ll be some nice overhead right there, base64 on every iteration :)
Flowmoparisthebest, I think the destination server should see the sender address
moparisthebestand I think you get the key for otherserver.com from DNS
moparisthebestwell that's what you are trying to avoid Flow
Flowyou 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
moparisthebestwould also have an odd side-effect, today you run 1 server for you and all contacts to minimize servers with full metadata
moparisthebestthis would only give you extra security with different servers
FlowBut that's a discussion from when the first wild ProtoXEP appears
Flow*for
moparisthebestFlow, yea and probably the only solution is 'would you like to recieve onion messages from someone at otherserver.com'
Guushas left
Flowmayben even not that, because that would also cause your mobile radio to power up
moparisthebestyour server would only ask you once
danielhas left
moparisthebestor, once every X when it already had an active connection or whatever
Flowthat could work
jonaswhm, right, you can’t even filter by roster on the server side
nycoboard meeting?
jonaswexcept if you put some keys into the roster, too
moparisthebestnope no roster or precense or anything here
moparisthebestand you'd never want to send other stanzas to each other
jonaswmoparisthebest, right
jonaswI don’t like that
Guushas joined
jonaswI don’t see how you can have this in a sane manner.
moparisthebestit would involve a super extra level of opt-in :)
jonaswwhich doesn’t push all the validation load on the client
moparisthebestbut also, precense isn't important anymore remember? :)
moparisthebestconversations doesn't display it normally, for instance, and with offline/mam etc all working, no one cares
jonaswmoparisthebest, presence isn’t, but being able to filter messages by sender server-side is.
jonaswspam filtering essentially
moparisthebestyep you can only do by whole server this way
jonaswyes, which is bad
moparisthebestnot really if it's opt-in
jonaswI frankly don’t see this finding a serious user base
Flownyco, doesn't look like board meeting :(
nycoindeed
GuusArc was here an hour ago
nycoyep
moparisthebestjonasw, when has that ever stopped a xep or code :)
arcNyco we're on UTC
danielhas left
nycothis changes the hour of availability
dwdWhile 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).
nycofor me too
nycolet's remove timezones already, one planet, one time
SamWhitedIn the interest of making small, incremental changes let's remove DST first, then we can consider timezones.
dwdSwatch Internet Time in Beats?
nycomeanwhile we still have no board meeting...
nycook, gotta go ;-)
dwdnyco, As noted earlier, Martin's off sick so cannot (or rather should not) attend.
jonaswyou’re not his mom!kk
Syndacehas joined
danielhas left
dwdjonasw, True, but I can get Laura to say the same.
dwd(For the avoidance of doubt, Laura is not Martin's mum either)
XSF Discussion - 2017-11-08