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.
vanitasvitae
SamWhited: maybe because mine is a httpupload link?
vanitasvitae
Ah, maybe thats not the reason...
SamWhited
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)
SamWhited
Not a big deal, it just "feels" inconsistent
daniel
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
daniel
The muc does reflect that
SamWhited
That 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
Arc
well one's http vs https
Arc
is 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
Zash
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.
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
Ge0rG
How does the OOB tag interop with OMEMO? It's obviously leaking data, but what exactly? Is the password only contained in the body?
Zash
I am under the impression that it's just a special URL in the (encrypted) body, with the encryption key in the #this part.
zinid
leaking data my ass...
zinid
yet another round of bikeshedding
Bunnehhas left
Bunnehhas joined
Ge0rG
Zash: yes, that's how it works. But what is contained in the oob tag?
danielhas left
danielhas joined
Ge0rG
I would look up myself, but I don't have any OMEMOs
Zash
I don't believe there is one
nycohas left
nycohas joined
goffihas left
Ge0rG
Zash: 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
jonasw
Ge0rG: oob is safe enough for daniel, sims would not be: https://github.com/siacs/Conversations/issues/2637
Ge0rG
I'd probably consider the picture URL and file size to be private as well, but what do I know
Zash
Where's that blag that said that e2e crypto is basically just marketing fluff?
intosihas joined
Ge0rG
Hm. 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
jonasw
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)
jonasw
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)
jcbrandhas left
jonasw
but hey, we already agree on the input format, I think that’s really nice, and it’s nice to have that standardised.
Ge0rG
I only wish for a way to skip formatting when typing formulas
or any other content which shouldn’t be formatted for that matter. ✏
jonasw
but nobody listens to me
Zash
It seems weird to me to be XEPing what amounts to UI things
Ge0rG
Zash: because you are a server dev
Ge0rG
Zash: I care very much about UI things, and I want them consistent across implementations
Flow
I'm sure everybody already noticed that XHTML-IM/styling/markdown/bmh discussion related thing on HN: https://news.ycombinator.com/item?id=15646425
Ge0rG
This is the major weakness of XMPP. Every client works differently
Zash
But sometimes it is a strength.
jonasw
depends
jonasw
I think for each major workflow we’d need a set of clients covering each platform.
Zash
Altho according to some random Reddit thread I saw, none of the competition things work as they should in FOSS
jonasw
currently, conversations covers the "non-technical" workflow pretty well on mobile.
Ge0rG
Zash: yes, if you believe that you need the opportunity to differentiate on quality of implementation.
Zash
Well, optimally the differentiation would be on proirites, so you could find a thing that sucks in ways you don't care about.
Flow
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?
jonasw
Flow, I looked at References
jonasw
it would be a major (size) overhead to have a <reference xmlns="…"> element for each bit of markup though
Flow
jonasw, not reference
Flow
<bodytext/>
Flow
(see linked mail)
Steve Killehas left
Flow
Uh wait, maybe I misunderstood Dave's mail, he was probably just talking about factoring the data into an extra element
Flow
not using that as generic element which can be re-used by other xeps
jonasw
I think so, too
jonasw
but now I get what you meant
jonasw
it also isn’t in the final XEP
jonasw
(<https://xmpp.org/extensions/xep-0372.html>)
Flow
true, but the idea is appealing. such an generic element could also specify how it's used with non-<body/> body text
Flow
like the text found in OMEMO messages
Kevhas joined
jonasw
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/>.
la|r|mahas joined
jcbrandhas joined
jonasw
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...)
Flow
jonasw, i fear it's a bit more complicated than that
jonasw
(nor will it authenticate the markup, which is bad too)
jonasw
Flow, is it?
ralphmhas left
Flow
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)
jonasw
multiple unencrypted body elements must have xml:lang tags to distinguish them, as do <markup/> elements.
jonasw
I presume that this is the same for OX?
Flow
yep
Zash
What does happen if you have multiple bodies with e2e?
Flow
but I possibly place the xml:lang selector not in <markup/> but in the generic <bodytext/>
Flow
Zash, what happens if you have multiple bodies without e2e?
jonasw
Flow, that makes things more complex to parse and generate I think
Zash
I haven't a clue
jonasw
Flow, I think e2ee simply doesn’t allow that
jonasw
it’s also not a very common use-case in IM
Flow
OX does not forbit multiple <body/> elements
Flow
*forbid
jonasw
*currently deployed e2ee simply doesn’t allow that ;-)
daniel
Is there an OX implementation in smack Flow?
Flow
daniel, there is a branch a started a while ago
Flow
but nothing even prototypical
Flow
yet
pep.
jonasw: maybe you should cover the case in markups. How does it work when there are multiple bodies ATM? (Different xml:lang)
Flow
first ISR, then OX. that is the current order of my priorities ;)
jonasw
pep., 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
jonasw
pep., I agree
jonasw
it’s tricky to avoid though
jonasw
I’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
jonasw
pep., there you go
daniel
jonasw: aren't the > and * you use in your example kinda like markup information in the body?
daniel
Which the xep says you are trying to avoid?
danielhas left
pep.
That's why I don't like them
dwd
daniel, It's only bad if someone else does it.
jonasw
daniel, it’s not required for them to be there at all.
jonasw
they don’t carry any meaning.
lskdjfhas joined
jonasw
however, 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
dwd
pep., Fallback.
jonasw
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
Ge0rG
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.
jonasw
but in contrast to the Message Styling wire format, we could adapt to changing behaviours and trends in the meta-characters used by humans
jonasw
which 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
jonasw
pep., tend to agree.
jonasw
but some kind of fallback is needed.
pep.
Why?
jonasw
especially for quotations
jonasw
(not so much for lists)
Kev
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*.
jonasw
if 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
jonasw
pep., I think most XEPs either specify a fallback or fail gracefully.
Kev
And 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)
jonasw
Kev, my main problem with Message Styling isn’t that it does that, but that it doesn’t have an opt-in.
Syndacehas left
Ge0rG
Kev: actually, all clients support rendering it... as ASCII
pep.
Ge0rG: agreed
Kev
Ge0rG: Potato potato :)
danielhas left
jonasw
if we’re going to change the rendering with possibly removing charatcers (e.g. for quotations!), then it must be opt-in.
Kev
We should not be removing characters.
jonasw
and I think that it should still be opt-in even if those characters are preserved.
daniel
jonasw, isn't opt-in something your client should support?
jonasw
daniel, no, because the client can’t know if the sender intended it.
Kev
We should be rendering the existing characters with additional styling, or should have a local toggle.
Ge0rG
Kev: 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)
daniel
i'm not really sure what you mean by opt-in then
jonasw
daniel, an additional element to <message/> which indicates that the body can be interpreted according to the Message Styling rules.
Ge0rG
I think that when copy&pasting things from the IM client, the original body should be copied with all "markup" characters present as-is
Ge0rG
jonasw: that would be body-markup-hints?
daniel
jonasw, i can get on board with that
jonasw
Ge0rG, exactly.
jonasw
daniel, I said so on the list, nobody cared :(
Ge0rG
the sending client could pre-render markup in the input field and offer a button to strip markup
Ge0rG
so you can paste code.
Ge0rG
but then interop.
mimi89999has joined
Ge0rG
You can't fix Gajim overnight
jonasw
Ge0rG, lovetox can :)
Ge0rG
So we need two hints. One for "this is markup" and another for "this is definitively not markup"
daniel
i'm not really sure I want Flows xep for that though. because then styling would depend on Flows xep getting accepted
jonasw
daniel, I think flows xep was rejected anyways?
Zashhas left
Kev
Ge0rG: Isn't this similar to the "I meant what I sent" that I was talking about with not doing emoticon rendering?
dwd
daniel, It needs something like Flow's BMH. Not *exactly* it.
jonasw
dwd, I think in fact it pretty much needs that.
Kev
(Although not quite the same)
Ge0rG
Kev: I thought you were talking about the receiving side
Ge0rG
I'm still annoyed by some IM clients replacing (b) and (y) with random emoji.
jonasw
daniel, in fact, my arguments for opt-in were dismissed with something along the lines of "edge cases nobody should care about".
jonasw
Ge0rG, kill trillian with fire
Ge0rG
jonasw: also, Gajim.
daniel
jonasw, i'm trying to find your email in that huge bike shadding thread to give a thumbs up
jonasw
Date: Yesterday 19:29
jonasw
(CET)
jonasw
if that helps
Zash
destroyallsoftware?
daniel
it does
Ge0rG
Kev: "I meant what I sent" could be a BMH of "text/plain"
dwd
Ge0rG, I don't think we need the complexity of media typing here, actually.
Ge0rG
dwd: right, let's just invent a new name for it.
dwd
Ge0rG, Would you want text/html there?
jonasw
I get shivers.
jonasw
also, note that BMH is not Content types
dwd
Ge0rG, If anything, we want a media type of: `text/plain; format=XYZ`, with ZYX given by a BMH-a-like.
Ge0rG
Okay, BMH only relates to body, so "text/" is implicitly pre-set.
I don't like the use of the term "Language" in there.
Ge0rG
</bikeshed>
dwd
Ge0rG, Yes, excellent point, this is veyr much a bikeshed.
danielhas left
jonasw
BMH essentially foresaw Styling.
jonasw
> TODO: Shall we define your own subset of e.g. CommonMark, XMPPMark? :)
jonasw
(or shall I say, inspired?)
dwd
I think the writing was on the wall.
Ge0rG
dwd: as opposed to the exact BMH identifier string to be used for "this is not markup"?
dwd
Only we couldn't parse it properly because it turned out nobody knew what *this* meant.
Ge0rG
I still want code syntax highlighting.
dwd
Ge0rG, I'm not worried about clients heuristically doing that in ```these sections```.
danielhas left
Zash
What about `if(what){then()}`{.c}
Ge0rG
like heuristically rendering /italics/ and *bold*?
Ge0rG
Zash: I think it's sensible to keep syntax coloring to ``` blocks, not to `spans`
danielhas left
Ge0rG
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
dwd
Ge0rG, I think that's sensible. I'm not entirely sure about the middle case, but I don't care enough to object.
daniel
gajims current rendering is pretty annoying btw
jonasw
daniel, didit boldface everything between (*) and (*)?
daniel
yes
jonasw
kill it with fire
dwd
jonasw, Yup. Not a huge fan of that, nor leaving the *asterisks* in place.
dwd
jonasw, But as a heuristic solution it's OK, and 99% of the time gets things right.
jonasw
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.
Ge0rG
x * y - z * 3
zinid
easy to writer a parser they said
jonasw
Ge0rG, and I don’t think that’s an assumption an client operated by a human can reasonably have
dwd
jonasw, Ge0rG literally just outlined a way to communicate exactly that.
Ge0rG
jonasw: the sender needs to pre-render the markup in the input line of course.
daniel
zinid, the styling xep has a very straight forward parser
jonasw
dwd, sender as in the human operating the client, not as in the program
daniel
it's just about defining the rules properly
jonasw
Ge0rG, that’s a very complex thing not many clients will do.
Guushas left
Ge0rG
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.
zinid
daniel: can I use LALR(1) parser? if not, it's not simple
jonasw
Ge0rG, sounds like a plan!
jonasw
didn’t think of LMC in this context, kudos
jonasw
zinid, I think LALR(1) should do
zinid
jonasw: can I have grammar.y then? or should I write it manually because it's funny?
jonasw
zinid, I suggest that the XEP authors provide a formal definition of the grammer once it is accepted :)
zinid
jonasw: ok
Ge0rG
BNF FTW!
zinid
ABNF would be awesome, I could use ragel
jonasw
ABNF seems very reasonable considering that it’s the IETFs go-to representation for grammars.
daniel
Ge0rG, if we want to annotate i'd prefer the simpler 'opt-in' proposal jonasw had
Zash
Not EBNF?
jonasw
Zash, I always forget the exact acronym
@Alacerhas left
daniel
you could still to 'send lmc to remove style'
Ge0rG
daniel: the simpler opt-in mechanism requires all clients to update
Ge0rG
daniel: ah, LMC-based markup removal. Yeah.
Zash
jonasw: Looks like both ABNF and EBNF exist
jonasw
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.
archas left
archas joined
daniel
Ge0rG, most clients need to update anyway. because gajim doesn't support styling for example
jonasw
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.
jonasw
Ge0rG, re code blocks, by the way, a common convention is "```language\n<code here>\n```"
jonasw
that’s how gitlab markup does it
Ge0rG
jonasw: yeah, I could live with that.
Zash
That's how pandoc does it.
@Alacerhas joined
mimi89999has left
Guushas left
Ge0rG
re "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
jonasw
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
Ge0rG
History is repeating.
Ge0rG
Can't we just change the message type? (I mean the 'type' attribute of the <message> stanza)
jonasw
Ge0rG, go away.
jonasw
;-)
Tobias
Ge0rG, i think the RFC doesn't allow additional parameters on that
Tobias
or additional attributes on body
jonasw
namespaced attributes! (Sam is gonna shoot me)
Ge0rG
Tobias: we can override the RFC with an XEP. I'm sure nobody will notice.
Zash
jonasw: y u do this
jonasw
Zash, what?
Zash
jonasw: mention namespaced attributes :)
jonasw
I think they’re great.
Ge0rG
do they need namespace versioning as well?
jonasw
sure
jonasw
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.
jonasw
or 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
Kev
Well, also whether you want what people already type to be correctly handled everywhere.
jubalhhas joined
jonasw
Kev, no, that’s input conventions and should not matter for wire formats.
Kev
Assuming universal adoption.
Kev
But this 'just render what's sent with styling enhancement' has been in use for a very long time without issue.
jonasw
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.
jonasw
(mostly because XML can’t carry those, but also because it’s not a useful plaintext fallback)
Zash
I like arguments like "everyone is already doing it" and "has worked forever without issue"
jonasw
Kev, I doubt you can say "without issue" just 50 lines after somebody complained about how broken gajim handles that.
Zash
Especially when people are pointing out the times it's messy and doesn't work
mathieui
jonasw, which is why I’ll wirte a protoxep in order to send the poezio internal format over the wire, escaped✎
mathieui
jonasw, which is why I’ll write a protoxep in order to send the poezio internal format over the wire, escaped ✏
Kev
jonasw: Gajim may do something stupid, but Psi doesn't.
nycohas left
Kev
I'm not saying that doing other things than what I'm suggesting works without issue :)
jonasw
Kev, 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
Kev
It would certainly bring into question that point that I'm not making, yes.
@Alacerhas left
Kev
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.
nycohas joined
jerehas joined
jonasw
Kev, "without issue" is certainly wrong, but I’m not going to nitpick here (and I probably misread some statement)
Kev
What's the issue with what Psi's doing?
jonasw
I don’t know psi, but what gajim does is certanily an issue.
jonasw
so it’s not without issue at all.
Kev
It basically just turns *thing* into <b>*thing*</b>
mathieui
jonasw, Kev’s point is that it has been in use for a long time without issue, in psi
mathieui
which is not contradicted by "gajim handles things wrong"
Kev
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".
Steve Killehas left
jonasw
Kev, 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)
Kev
Just adding styling to ** // __.
jonasw
Kev, well gajim does exactly that
Kev
(Without removing the characters)
Kev
If Gajim does exactly that, what's the issue?
jonasw
it also does that across newlines
mathieui
jonasw, gajim has somewhat looser boundaries
mathieui
I think psi only does it for words
jonasw
mathieui, Kev didn’t say anything about boundaries :-)
mathieui
e.g. the formating chars are stuck to the words
@Alacerhas joined
goffi
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?
Steve Killehas joined
Kev
I forget, I wrote this a decade and a half ago or so.
mathieui
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
Kev
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.
Kev
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.
Kev
But ISTR I made Psi not do word partials.
jonasw
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)
valohas joined
Kev
There *is* a definite advantage to having this out of band, BTW, which is that you can not annotate things that are pastes.
Kev
But I think you can achieve the same thing just by having <paste/> as a child.
Kev
AFK 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
moparisthebest
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"
Zash
/thread
jonasw
itym </thread>?
zinid
*thread*
Ge0rG
*italics*
mathieui
i*italics*
intosi
["The last word should be ", {"style": "bold", "contents": "bold"}]
Zash
Let me tell you about `pandoc -t json`
intosi
Can I still say no?
intosi
Or rather, [{"unMeta":{}},[{"t":"Para","c":[{"t":"Str","c":"No!"}]}]]
dwd
I'm concerned that "No" is not semantically transmitted, and therefore may be interpreted differently in multiple clients.
Guus
dwd: I see that you're married.
dwd
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.
Ge0rG, And from there, but a short step to eliding the communication entirely, making XMPP so much more bandwidth efficient.
intosi
I would propose BER, but I'm too lazy to do so.
Zash
B2B communication
dwd
intosi, PER, surely, or does David no longer get excited by that one?
Zash
intosi: have you considered beer instead
Ge0rG
dwd: that's absolutely the wrong direction. We can finally increase XMPP's popularity by populating the network with m2m semantics-capable clients
intosi
Zash: +1
intosi
dwd: 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'/>
moparisthebest
I'm super sorry to turn the topic of conversation here, but, Zash about layers of encryption so each server only knew bare minimum
moparisthebest
seems like it could still be XMPP but we'd just have to wrap things in new nonzas ?
jonasw
moparisthebest, 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>
jonasw
moparisthebest, what about presence broadcast, MUC?
moparisthebest
jonasw, not sure, maybe it only works for messaging
jonasw
MUC and MIX broadcasts?
Ge0rG
jonasw: encrypted to the MUC service
Ge0rG
jonasw: or multi-key-encrypted to all participants
moparisthebest
it might only be feasible for bare-minimum metadata for direct chats
moparisthebest
yea that'd work I guess, let the MUC service broadcast, idk
moparisthebest
just trying to throw crazy ideas out there that solve the metadata problem as much as possible
jonasw
I don’t think that there is a real metadata problem.
moparisthebest
we are OK with specs that require changes on all clients and servers to be useable already, see MIX
jonasw
or maybe there is, but I don’t think it’s reasonable to solve that within XMPP.
moparisthebest
might as well solve the metadata problem the same way
Ge0rG
moparisthebest: the best solution to the metadata problem is to run your own server for you and all of your important contacts
SamWhited
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)
moparisthebest
doesn't *solve* it, you still have 1 central service that knows everything
zinid
moparisthebest: solve what?
Ge0rG
moparisthebest: federated systems will always have metadata leakage. What you want instead is a P2P DHT chat system.
jonasw
SamWhited, okay
moparisthebest
metadata problem
Ge0rG
moparisthebest: or maybe you want to connect to XMPP via TOR.
moparisthebest
if I wanted that I'd just use tox, and have to change my phone battery every 20 minutes
moparisthebest
I'm just talking about leaking bare minimum metadata to XMPP servers, the bare minimum for federated chat
Ge0rG
moparisthebest: so what you want instead is a tox agent running on a trusted server that you connect to.
moparisthebest
then you are back to 1 central server with all info
Ge0rG
moparisthebest: yes.
moparisthebest
so you've got A (client) -> B (server) -> C (server) -> D (client)
Ge0rG
moparisthebest: with XMPP, you could hide the usernames of the people you talk to from your server. But not presence.
moparisthebest
an ideal scenario has each only knowing about the next hop
Ge0rG
moparisthebest: and then still, the receiving server would know your full JID.
moparisthebest
no they'd only know the server it came from, and who it's going to, not sending JID though
jonasw
moparisthebest, that doesn’t buy you a lot, you’d need to go full Tor essentially
moparisthebest
I think it does buy you a lot
moparisthebest
no server knows who sent it or who it's intended for
moparisthebest
and that's the win you are looking for
moparisthebest
worded that wrong, let me try again...
jonasw
it needs to know who sent it to be able to reply with an error
Zash
moparisthebest: howaboutno
moparisthebest
no single server knows who sent it or who it is intended for
moparisthebest
damnit
moparisthebest
no single server knows BOTH who sent it AND who it is intended for
moparisthebest
finally, need more coffee
jonasw
moparisthebest, the destination server needs to know both
Ge0rG
moparisthebest: then you have to filter spam at the client.
jonasw
it needs to be able to deliver it to the client locally
jonasw
and it needs to be able to reply with an erro
jonasw
to the original sender
moparisthebest
jonasw, right, to the original sender's SERVER
moparisthebest
who then handles it from there
jonasw
and how would that know where to send it?
moparisthebest
that's encrypted so only the senders server can decrypt it
jonasw
I see
moparisthebest
Ge0rG, yep you always have to with e2e meh
jonasw
moparisthebest, incorrect
jonasw
whatsapp and others filter spam solely based on metadata
moparisthebest
and here you have even less metadata
jonasw
email spam is also filtered based on metadata to a large extent (DNSBLs for example)
moparisthebest
which is in fact the entire point
jonasw
yes, but that’s not a property of e2ee
moparisthebest
you can still filter the DNSBL way, ie, blocking the whole server
moparisthebest
but that's it
moparisthebest
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
waqashas joined
Zash
Insufficient context
Guus
I know I'm late to the party, but: <response thread="ban-opposing-sides"/>
Guus
threat!
jonasw
Zash, I guess it’s 14:16:46 Zash> moparisthebest: howaboutno
moparisthebest
yep
Zash
On phone, it scrolled out of view.
Zash
Anyone wanna add a in-reply-to equivalent thing to XMPP ?
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
>> 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.
Zash
Maybe you can infer from nickname prefix
moparisthebest
sorry what's this > business in front of your messages SamWhited ? I don't understand /sarcasm /no-need-to-respond :)
jonasw
SamWhited, I learnt that the hard way while reading The Hitchhikers Guide to the Galaxy for the first time.
Guustips hat.
SamWhited
jonasw: 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?
jonasw
I have an issue with XEP-0153 :/
jonasw
it’s the whole damn thing :P
lovetox
yeah i dont get that, xep-0153 covers all use cases in my opinion, i dont know why we every would need more
lovetox
the only thing that can be said thats not so nice is, that you can request the avatar alone
jonasw
lovetox, notification on change?
Link Mauve
jonasw, it’s a thing which works, today, in every case.
lovetox
and also have to request whole vcard
Link Mauve
jonasw, presence update.
lovetox
jonasw, presence?
jonasw
oh
lovetox
but avatar data will always way more then vcard data
lovetox
so not that big of a problem
jonasw
I didn’t know that
lovetox
then you never read 0153
jonasw
I admit that
jonasw
I read the title and that it was historical and assumed it’d be polling the vcard
Link Mauve
Long ago I wanted to add a vCard value for 0084 too, but I never followed on that.
nycohas left
zinid
Link Mauve: I have no problems with 0153, I have problems with 0153 and 0084 being implemented by different clients
zinid
Link Mauve: also 0084 doesn't work in mucs
zinid
and now we're doing the same weird shit with vcard-4
jonasw
I heard nobody uses vcard-4?
zinid
jonasw: MIX suggests it for example
lovetox
no though i plan to use it
edhelas
jonasw I do, over PEP
edhelas
works great
lskdjfhas joined
nycohas joined
zinid
ok, we probably need to say good bye to vcards as well
zinid
so no avatars, no vcards, no private storage, no file sharing
zinid
that's where we are in 2017
lumihas left
zinid
and you are discussing how to transfer bold
zinid
amusing
mathieui
zinid, I want to transfer italics, not bold!
edhelas
yup
edhelas
zinid I do agree, and bookmark is still broken and non-atomic :p
zinid
yes, bookmarks are broken as well because of incompatible implementations
jonasw
hopefully we can settle all of this if multi-item PEP lands✎
jonasw
hopefully we can settle all of this when multi-item PEP lands✎✏
jonasw
hopefully we can settle all of this when multi-item private PEP lands ✏
Holger
We'll still have 2-3 XEPs for transmitting bold then :-)
edhelas
jonasw PEP could be just Pubsub on JID <3
Link Mauve
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.
edhelas
🦄
Link Mauve
vCard 4 is also something which should be replaced with vCard.
Holger
Link Mauve: I think we are the stupid ones in failing to agree on a solution for a given problem.
Holger
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.
zinid
Link Mauve: should be replaced? like in https://xkcd.com/927 ?
Link Mauve
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.
edhelas
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
SamWhited
Holger ++
Link Mauve
Holger, yes, I agree.
edhelas
also with Prosody having persistance and Pubsub now we will be able to use PEP for mostly everything
Link Mauve
edhelas, not really, no.
jonasw
Link Mauve, excuse me, if I am faced with a choice between a Draft and a Historical XEP, I’m going to implement Draft.
Ge0rG
edhelas: prosody isn't even there yet
Link Mauve
0084 is still fundamentally broken, despite persistency in one specific implementation.
jonasw
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.
Link Mauve
jonasw, yes, the state of these XEPs is sad.
edhelas
Link Mauve why 0084 is broken ?
georghas left
zinid
edhelas: it doesn't work in mucs
jonasw
if it’s not supposed to be implemented, council should make sure that it doesn’t look like one should
edhelas
ah yes MUC…
edhelas
let's talk about vcards and avatars for Pubsub nodes as well
jonasw
but I firmly reject to be the "stupid one" here.
Link Mauve
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.
edhelas
basically what we are trying to do with MIX
Link Mauve
jonasw, as Holger pointed it, it’s not users or developers who are the stupid ones, but the XSF and our current standardisation process.
jonasw
XEP-0048 is even worse because you can’t easily discover that the whole way to store it was changed
edhelas
allowing PEP for any nodes and JID would be nice
Link Mauve
jonasw, yes.
jonasw
Link Mauve, oh, I missed that :(
zinid
edhelas: but how? by obligating a user's server to keep MIX metadata?
edhelas
for example a MUC admin can set a vcard node to his MUC
Link Mauve
edhelas, you can already do that though.
jonasw
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.
edhelas
jonasw roled back to private-xml ?
jonasw
edhelas, yes
edhelas
hell no
jonasw
not becaiuse of technical superiority, because it was incredibly wrong procses-wise
edhelas
jonasw I'd like to manage bookmarks this way https://xmpp.org/extensions/xep-0330.html
jonasw
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!
edhelas
as I said, if PEP will be correctly implemented it would unlock many possibilities
edhelas
even if avatars for mucs will not be solved…
edhelas
Link Mauve what is missing in Prosody to have proper PEP support (persistance and pubsub stuff related) ?
edhelas
last time I've checked it was getting there
pep.
edhelas, isn't it in trunk already? just the flag that's not turned on
edhelas
well yeah
edhelas
I have some minor issues with configure on create but it was fine overall (thanks again for the work btw)
edhelas
I 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)
Holger
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?
lskdjfhas joined
edhelas
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…)
lovetox
lol Holger, i definitly depend on that
Holger
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? :-)
lovetox
madness
edhelas
and naturally the messages containes <x> muc tags then I can differenciates vcards that are coming from resources
danielhas left
Guushas left
edhelas
could work no ?
waqashas left
danielhas left
arc
Morning
arc
Its meeting time apparently , anyone else here?
dwd
arc, You're aware of TZ changes? I don't know what Board agreed WRT handling those.
arc
1600utc this is the time
Guus
Indeed 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)
arc
Iirc I copied guus's calendar entry to my own
dwd
OK. It *is* Council at this time too. Also Martin is off sick, so he shouldn't be attending.
arc
What tz is council meeting at?
jjrhhas left
Guus
dwd: see calendar: you guys then agreed to do that in UTC too
Guus
Completely 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
moparisthebest
are nonzas used in other places than CSI or defined someplace?
jonasw
moparisthebest, there are quite a few nonzas in RFC 6120
jonasw
(sasl, starttls, stream features, are there more?)
moparisthebest
doesn't actually mention the term 'nonza' though, but yea
moparisthebest, careful, the term nonza is another thing where the community can be split in two halves.
danielhas left
lovetoxhas left
Flow
With most things you will find someone raising a voice against…
Flow
And of course having a well defined term for something we didn't have an unambiguously (short-)term before is very helpful
moparisthebest
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.
moparisthebest
hmm, so what if one wanted to introduce a new nonza-like thing but that did get routed with specific routing rules?
danielhas left
jonasw
that’s a something-za then
moparisthebest
what would you call that, a rononza ?
jonasw
ronza?
jonasw
;-)
Flow
moparisthebest, I'm not sure if you could introduce such a thing even if the nonza xep didn't exist
jonasw
frankly, 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)
SamWhited
moparisthebest: that would be against 6120, if I'm not mistaken
jonasw
SamWhited, does RFC 6120 forbid routed elements wihch are not <iq/>, <message/> or <presence/>?
Flow
jonasw, not explicitly, but how is that supposed to work with federation?
jonasw
Flow, moparisthebest plans some negotiation
SamWhited
Oh, I thought it did explicitly, but maybe not
Kev
Flow: Same as everything else, with negotiation.
moparisthebest
yea it'd be opt-in
Flow
moparisthebest, what if the recipient is offline?
Flow
(it possibly would help if I knew what excactly you trying to achieve ;))
moparisthebest
onion xmpp, minimum-metadata xmpp, not sure, naming is one of the hard problems
Flow
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
moparisthebest
don't those have to have a from and to ?
moparisthebest
I guess maybe you could still hack it in
Flow
no
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>
moparisthebest
that's something like what I'm thinking
moparisthebest
each server only knows the hops next to it, no single server knows which 2 clients are talking
jjrhhas left
Flow
Nice idea
moparisthebest
hopefully in that way things like carbons/mam/offline/sm etc etc all work the same
dwd
moparisthebest, That's how Tor works, indeed. More or less.
jonasw
moparisthebest, wrapping everything in <message/> addressed to the next hop would probably work
moparisthebest
yea and from the one it can know probably
marchas left
Flow
and would give you SM greatness
danielhas left
jonasw
ack
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>
dwd
Where do you put the security label?
jcbrandhas left
moparisthebest
well you'd have to put those in a new tag inside message of course
moparisthebest
but that's the general idea
jonasw
that’ll be some nice overhead right there, base64 on every iteration :)
Flow
moparisthebest, I think the destination server should see the sender address
moparisthebest
and I think you get the key for otherserver.com from DNS
moparisthebest
well that's what you are trying to avoid Flow
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
moparisthebest
would also have an odd side-effect, today you run 1 server for you and all contacts to minimize servers with full metadata
moparisthebest
this would only give you extra security with different servers
Flow
But that's a discussion from when the first wild ProtoXEP appears
Flow
*for
moparisthebest
Flow, yea and probably the only solution is 'would you like to recieve onion messages from someone at otherserver.com'
Guushas left
Flow
mayben even not that, because that would also cause your mobile radio to power up
moparisthebest
your server would only ask you once
danielhas left
moparisthebest
or, once every X when it already had an active connection or whatever
Flow
that could work
jonasw
hm, right, you can’t even filter by roster on the server side
nyco
board meeting?
jonasw
except if you put some keys into the roster, too
moparisthebest
nope no roster or precense or anything here
moparisthebest
and you'd never want to send other stanzas to each other
jonasw
moparisthebest, right
jonasw
I don’t like that
Guushas joined
jonasw
I don’t see how you can have this in a sane manner.
moparisthebest
it would involve a super extra level of opt-in :)
jonasw
which doesn’t push all the validation load on the client
moparisthebest
but also, precense isn't important anymore remember? :)
moparisthebest
conversations doesn't display it normally, for instance, and with offline/mam etc all working, no one cares
jonasw
moparisthebest, presence isn’t, but being able to filter messages by sender server-side is.
jonasw
spam filtering essentially
moparisthebest
yep you can only do by whole server this way
jonasw
yes, which is bad
moparisthebest
not really if it's opt-in
jonasw
I frankly don’t see this finding a serious user base
Flow
nyco, doesn't look like board meeting :(
nyco
indeed
Guus
Arc was here an hour ago
nyco
yep
moparisthebest
jonasw, when has that ever stopped a xep or code :)
arc
Nyco we're on UTC
danielhas left
nyco
this changes the hour of availability
dwd
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).
nyco
for me too
nyco
let's remove timezones already, one planet, one time
SamWhited
In the interest of making small, incremental changes let's remove DST first, then we can consider timezones.
dwd
Swatch Internet Time in Beats?
nyco
meanwhile we still have no board meeting...
nyco
ok, gotta go ;-)
dwd
nyco, As noted earlier, Martin's off sick so cannot (or rather should not) attend.
jonasw
you’re not his mom!kk
Syndacehas joined
danielhas left
dwd
jonasw, True, but I can get Laura to say the same.
dwd
(For the avoidance of doubt, Laura is not Martin's mum either)