I hope that Link Mauve eventually reconsiders his vote, because maybe he was also on the wrong track about what BMH is about…
mimi89999has joined
lovetoxhas joined
Guushas left
Guushas joined
danielhas left
Guushas left
jubalhhas joined
Guushas joined
jubalhhas left
jubalhhas joined
jubalhhas left
Steve Killehas left
Zashhas left
Zashhas joined
Steve Killehas left
Steve Killehas joined
pep.
Flow: I don't think so
jonasw
Flow, to be honest, I think you picked a really bad time for this
jonasw
the worst imaginable
jonasw
I now understand your use-case, but in light of the XHTML-IM obsoletion discussion ...
Zash
I had that thought as well
pep.
And I said that on the ML already
pep.
Plus, I don't see what your XEP brings that's not already possible for you to do in your gateway, instead of pushing that effort on every. single. client.
Steve Killehas left
Steve Killehas joined
dwdhas left
tim@boese-ban.dehas left
dwdhas left
pep.
If the XSF wants to avoid flawed implementations BTW (seeing the xhtml-im thread), I suggest we start here
tuxhas left
dwdhas left
dwdhas left
Flow
jonasw, Zash: Yep you are right. I blame our Ignite Realtime community for switching to Discourse and triggering the whole BMH idea. And by the time I realized that it could be seen as suggestion for a potential XHTML-IM replacement, the XEP was already announced without a good introduction providing a motivation. I would be happy to change that, but as long as there is a -1 vote from Link Mauve I'm not sure if I should put any more effort into it.
dwdhas left
jonasw
blaming the people who switch to Discourse is in any case the right thing to do
Flow
(of course I'm the only one to blame here, can't tell you how excited I'm that Ignite Realtime finally switched to discoures)
jonasw
(I’m not sarcastic here :))
Zash
Like I said earlier, I blame the web.
jonasw
blaming the web wfm too :)
Flow
yeah, everyting was better when we still had gopher
Zash
Flow: A very clear problem statement in the introduction probably helps.
jonasw
gopher was amazing
Zash
I never used it, but everything *was* better
zinid
what's wrong with discourse?
jonasw
I wrote a gopher server once, in freepascal.
jonasw
then firefox dropped gopher support :(
Zash
I looked into the specs and almost started implementing it in Prosody :)
Ge0rG
can't we just go back to NNTP?
jonasw
NNTP over NTP
Zash
From what I gather, NNTP was perfection.
Archas left
zinid
NNTP was quite good indeed
Ge0rG
Zash: except for the spam.
jonasw
it’s always the spam
Zash
Not quite clear on the distinction between NNTP, Newsgroups and usenet.
Ge0rG
Oh wait. XMPP is the NNTP of the 2000s.
Ge0rG
Zash: similar to the distinction between XMPP and Jabber.
jonasw
XMPP, Jabber, conversations.im?
Zash
It was pure perfection anyways. Therefor it must die.
dwdhas left
Zash
The Web will win and consume the world, because it is terrible.
Zash
Can't have nice things.
Zash
Worse is better.
Ge0rG
So I've spent two hours tracking the special place where Android devices store their factory-reset-protection data, just to realize that I have no actual device supporting it.
Real-Time Communications dev-room: deadline 23:59 UTC on 30th of November.
dwdhas left
dwdhas left
la|r|mahas joined
dwdhas left
lskdjfhas joined
danielhas left
danielhas joined
dwdhas left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
dwdhas left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
pep.has left
Wiktorhas left
nycohas left
dwdhas left
goffihas left
jerehas joined
dwdhas left
dwdhas left
mimi89999has joined
dwdhas left
dwdhas left
emxphas joined
goffihas joined
dwdhas left
dwdhas left
emxphas joined
tux
Ge0rG: you mean there are Android devices with a special storage area for malware?
dwdhas left
Ge0rG
tux: no, it's more of a trojan horse when you sell your android device.
dwdhas left
tux
👍
Ge0rG
tux: after a factory reset, the device can only be unlocked with the gmail account that was used on it before resetting.
tux
Effectively opening a market for Gmail account data.
dwdhas left
danielhas left
jerehas left
jerehas joined
lumihas joined
dwdhas left
ralphmhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
ralphmhas left
Alexhas joined
dwdhas left
jubalhhas joined
ralphmhas joined
dwdhas left
dwdhas left
tim@boese-ban.dehas left
tim@boese-ban.dehas left
tim@boese-ban.dehas left
tim@boese-ban.dehas left
tim@boese-ban.dehas joined
tim@boese-ban.dehas left
tim@boese-ban.dehas joined
tim@boese-ban.dehas left
dwdhas left
dwdhas left
dwdhas left
valohas joined
dwdhas left
dwdhas left
valohas joined
dwdhas left
dwdhas left
nycohas left
dwdhas left
Zashhas left
dwdhas left
dwdhas left
sonnyhas joined
sonnyhas joined
dwdhas left
danielhas joined
dwdhas left
dwdhas left
jubalhhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
jerehas joined
jerehas joined
jubalhhas left
danielhas left
dwdhas left
danielhas joined
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
Wiktorhas left
jerehas left
dwdhas left
dwdhas left
Zashhas left
emxphas left
jubalhhas joined
stefandxmhas left
zinidhas left
emxphas joined
ralphmhas left
jubalhhas joined
vanitasvitaehas joined
jubalhhas joined
jjrhhas left
lskdjfhas left
Guushas left
Guushas joined
jerehas joined
jjrhhas left
jjrhhas left
dwdhas left
jjrhhas left
tim@boese-ban.dehas left
jubalhhas left
jjrhhas left
dwdhas left
dwdhas left
Archas joined
dwdhas left
lskdjfhas left
lskdjfhas joined
dwdhas left
lskdjfhas left
lskdjfhas joined
dwdhas left
jjrhhas left
jjrhhas left
stefandxmhas joined
dwdhas left
jjrhhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
danielhas left
danielhas joined
dwdhas left
dwdhas left
stefandxmhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
sonnyhas left
sonnyhas joined
sonnyhas joined
dwdhas left
sonnyhas joined
dwdhas left
mimi89999has left
danielhas left
danielhas joined
dwdhas left
tuxhas left
tuxhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
tuxhas left
dwdhas left
dwdhas left
dwdhas left
emxphas joined
emxphas joined
tuxhas joined
tuxhas left
dwdhas left
dwdhas left
danielhas left
danielhas joined
Zashhas left
dwdhas left
dwdhas left
Zashhas left
dwdhas left
sonnyhas joined
dwdhas left
zinidhas left
waqashas joined
jubalhhas joined
jjrhhas left
vanitasvitaehas left
stefandxmhas joined
jjrhhas left
jjrhhas left
vanitasvitaehas joined
intosihas joined
Guushas left
danielhas left
danielhas joined
Guushas joined
matlaghas joined
jjrhhas left
zinidhas left
uchas joined
jjrhhas left
uchas joined
Guushas left
boothj5has joined
Guushas joined
ralphmhas joined
boothj5has left
dwdhas left
dwdhas left
dwdhas left
vanitasvitaehas left
dwdhas left
dwdhas left
emxphas left
dwdhas left
dwdhas left
lumihas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
jubalhhas left
jjrhhas left
jerehas joined
dwdhas left
Valerianhas joined
dwdhas left
dwdhas left
stefandxmhas left
emxphas joined
Kevhas left
jjrhhas left
jerehas joined
dwdhas left
jubalhhas joined
jubalhhas left
dwdhas left
vanitasvitaehas joined
lskdjfhas left
lskdjfhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
jjrhhas left
dwdhas left
dwdhas left
dwdhas left
sonnyhas joined
dwdhas left
dwdhas left
waqashas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
Archas left
dwdhas left
dwdhas left
lumihas joined
archas left
archas joined
stefandxmhas joined
archas left
archas joined
dwdhas left
Link Mauve
“19:13:59 Flow> What do clients use these days to embed image-urls into a message (e.g. for stickers)?”, Movim uses XHTML-IM, alongside BoB.
sonnyhas joined
dwdhas left
Flow
Link Mauve, k, thanks. I wonder if at least OOB should be mentioned in https://xmpp.org/extensions/xep-0387.html#im
Link Mauve
I doubt so, it’s one of these XEPs that should be deprecated imo, it brings pretty much no information.
SamWhited
I think one of those two things (SIMS or OOB) could be included (in the next version which I will start on as soon as this one is advanced). It makes the experience significantly nicer.
Flow
what was SIMS again?
SamWhited
Flow: Slightly more advanced OOB, I think. I need to read both again and compare.
Link Mauve
Flow, about Discourse, I really fail to see the issue with doing exactly the same thing as every other gateway before yours, that is to convert whatever input markup you get from the legacy service into both plain text and XHTML-IM.
dwdhas left
SamWhited
Eg. allows for multiple media types.
Link Mauve
Flow, 0385.
jonasw
Flow: Stateless Inline Media Sharing
Flow
Link Mauve, how do you image a plain text version of CommonMark look like?
Link Mauve
Basically, a description of the file, with metadata, and multiple possible sources to retrieve it.
Link Mauve
Flow, for example “this is **bold**” into “this is bold”.
Link Mauve
That way the receiver won’t have to understand CommonMark to understand a sentence.
Flow
so I need to converters and loose stylistic/semantic information if the recipient can only look at the body?
dwdhas left
Flow
Do we also convert lists?
Link Mauve
Right, that’s the definition of plain text.
Flow
And headings?
Link Mauve
Indeed, you should convert the usual Markdown list (this one:
1. first item
1. second item
1. third item
) into something that can be better understood by the user.
Flow
And why would I convert at all? CommonMark is nicely readable as plain text
Link Mauve
Here, renumbering them into 1. 2. 3.
moparisthebest
why isn't commonmark in the body with some clients displaying it raw and some translating it on the recieving end like every email/chat client ever fine?
Link Mauve
Flow, it’s not always, I just gave you two examples.
dwdhas left
SamWhited
Messing with the message the user sent seems like a bad idea, especially when it's already perfectly readable plain tex.t
moparisthebest
gajim, all IRC clients, most email clients, they all do that
goffihas left
Flow
Link Mauve, that's a corner case, and I believe you will get normalized CommonMark out of Discourse
dwdhas left
moparisthebest
also the *huge* problem with not putting things in body, or different representations, is from a security perspective, how do you ensure they are the same? jonasw I think you were the most concerned with using body
Link Mauve
moparisthebest, email clients overwhelmingly display the text/html version of a multipart attachment first, some of them display the text/plain version and add colour for common idioms, such as the “-- ” signature or the ”>” quotes but that’s due to legacy.
sonnyhas joined
moparisthebest
due to legacy sure, but it works great and everyone understands it
Flowhopes that the text/plain MIME part never becomes legacy
Link Mauve
If I want to display you a broken ordered list, what I just posted you, will you also transform that into a normalised one creating incomprehension between us, just because you happen to throw every incoming message into your CommonMark parser?
moparisthebest
what flow just did, /me, is that a XEP someplace or is that convention?
Link Mauve
Flow, same. ^^
SamWhited
More importantly, people who have never seen it before intuatively understand it. If you read "Wow, that's *amazing*!" you just get it… it makes sense that it's a for of emphasis.
SamWhited
*form of
dwdhas left
jonasw
moparisthebest: consistency of user experience, fracturing of the ecosystem and complexity of supporting possibly numerous markups
yea, and gajim bolded that for me as well, equally I would have understood if it didn't
jonasw
I'm on the phone now
jonasw
so hard to go into details
Zash
Flow: You didn't see the thing where some Mozilla person wanted to remove plain text because it didn't have tracking images?
moparisthebest
ah nifty SamWhited , also just in body, and if the client didn't support it it'd still be mostly readable
Flow
Zash, I read about it :)
Flow
bbl
moparisthebest
imho that's what you want for instant message markup, simple things that don't matter if they are actually interpreted or not *bold* /italic/ etc
moparisthebest
publishing blog posts is a different use-case with different needs
dwdhas left
dwdhas left
Zash
Formatting vs semantics again
Link Mauve
moparisthebest, that’s a Gajim bug, not something we should encourage.
Link Mauve
(Bolding something.)
moparisthebest
don't many other clients do the same?
moparisthebest
seems like it should be a feature we should encourage to me
Link Mauve
moparisthebest, I’ve never seen any other client, and it sounds misguided at best.
stefandxmhas left
moparisthebest
it's at minimum in basically every irc client and most email clients
moparisthebest
surely it's in other xmpp clients
dwdhas left
pep.
I agree with Link Mauve, that's not something that should be encouraged. Or at best gajim could translate that to xhtml-im
lskdjfhas left
moparisthebest
my point is it's readable whether the client special-cases it or not
moparisthebest
no fragmenting or confusion
dwdhas left
SamWhited
I disagree, it's simple, effective, and a very nice experience. We should absolutely encourage it.
pep.
moparisthebest, it's not because you understand it that everybody does. My parents don't, they might understand *foo*, but maybe not _bar_ nor /baz/
pep.
Also if a client translates that, how do I write IPA now? :(
SamWhited
(or we should absolutely encourage something similar, I'm not advocating for exactly what Gajim does, whatever that may be)
dwdhas left
Link Mauve
(I just reported that bug to Gajim, fyi.)
SamWhited
I don't even think that needs to be standardized though; it could be completely separate from whatever new formatting thing comes out. It's just nice to have either way and can be client specific without harming anything.
Steve Killehas left
pep.
By using common characters as meta characters you are removing many things that were possible and won't be anymore. Have your client allow you to write rich text, sure, don't clutter <body>
dwdhas left
moparisthebest
pep., but then evil alice can send 1 message with something different in <body> and <somefancymarkup>, it opens up a bad can of worms
moparisthebest
pep., won't they understand _bar_ or /baz/ , and if not, why exactly does it matter?
pep.
because I want to express something if I use that?
moparisthebest
by the way I'm using gajim now and it still *shows* all the characters, just additionally underlines/bolds/italics them
pep.
I want their client to convey it for me, they know what italic is, what bold it, they might not know what **, __, or // are
pep.
Or whatever other markup you fancy
moparisthebest
here's the other thing, I don't want to read your fancy markup, so I can turn it off on my client
dwdhas left
moparisthebest
if your client sends it in <newfancymarkup> then I have to view that
moparisthebest
I don't have an option not to see it
goffihas joined
Link Mauve
moparisthebest, err, Markup isn’t plain text, it just isn’t.✎
Link Mauve
moparisthebest, err, Markdown isn’t plain text, it just isn’t. ✏
dwdhas left
moparisthebest
it is though, it's made to be perfectly readable as plain text
moparisthebest
and maybe parts are a bit questionable but that's fine, we only want the super simple obvious parts
Link Mauve
If I don’t want to display formatting and turn it off in my client, when there is a plain text alternative I can, when you confuse Markdown and plain text I can’t anymore.
moparisthebest
except markdown is plain text
moparisthebest
or at least the subset that every chat program has been happy with for years
Link Mauve
moparisthebest, you may want only the very simple part, someone else may want one other part, and a lazy dev will shove you whatever their fancy lib supports.
dwdhas left
moparisthebest
no, that's the entire point
Link Mauve
moparisthebest, Markdown is a superset of HTML.
moparisthebest
you don't use a lib to send anything
pep.
moparisthebest, markdown is not plaintext. If you say that I say we should use escaped XML as markup language
Link Mauve
It’s not plain text, has never been.
dwdhas left
pep.
<strong>Hey!</strong>
moparisthebest
you send the exact text the user writes
moparisthebest
the recieving client displays it, optionally with a bit of formatting
moparisthebest
here I'll send a screenshot of what gajim displays so we are all on the same page *bold* _underlined_ /italic/
Link Mauve
moparisthebest, so how do you interpret what pep. just sent?
Link Mauve
moparisthebest, ah, but *bold* is actually italic in Markdown.
Link Mauve
Now what do you do?
sonnyhas joined
moparisthebest
I interpret it as, why the hell is he writing xml in a text chat
Link Mauve
While what pep. wrote is actually bold in Markdown.
Link Mauve
moparisthebest, but that’s Markdown he just wrote.
moparisthebest, in Mattermost, markup is correctly displayed without these ugly * and / and whatnot, the user can focus on the text and not on * which pollute the reading.
moparisthebest
pep and then you opened the can of worms, you are in a contract dicussion, and alice sends <body>that'll be $10,000</body><fancymarkup>that'll be $1,000</fancymarkup> and since you use fancyclient you agree, but oops the xsf log bot only supports <body> sucks to be you in court
moparisthebest
and a million other things
SamWhited
How does that not reflect what you wanted?
SamWhited
Or, put another way, why does it matter to you that on the other thing a thing you weren't expectint to be bold ended up bold?
pep.
How does gajim deal with both *foo*
SamWhited
(or italics, or whatever)
Link Mauve
pep., you mean this and *that*? :)
pep.
SamWhited, because that could be interpreted as an emphasis, which I didn't want
pep.
Link Mauve, no I meant both at the same time
Zash
moparisthebest: same with email and xhtml-im and everything
moparisthebest
then you shouldn't have used the characters that have meant emphasis for 20+ years pep.
archas joined
Link Mauve
I’d suppose it displays it normally-bolded.
dwdhas left
SamWhited
pep. what did you want then? Even if there is no bolding or highlighting, *this* looks like emphasis to me.
moparisthebest
and to everyone else
moparisthebest
that's why everyone uses them
pep.
SamWhited, moparisthebest, that's the magic of having markup separated from plaintext
SamWhited
I didn't understand that.
pep.
I used ** but it could have been __ or ^^ for all I care
Link Mauve
SamWhited, because you have been thinking with computers since forever, go in the street and ask a random person who seldom use a computer what * means, you’d be surprised.
moparisthebest
I highly doubt that
Link Mauve
(I know my mother once asked me about something similar, which I had always been using without thinking about it, I think it was the * used for corrections.)
moparisthebest
I think you send anyone something like *this* it's pretty apparant
SamWhited
I disagree, even if I've never seen it I'll probably see *wow!* and assume someone meant emphasis; your mother wouldn't even think of it, she'd just read it and naturally ignore it.
moparisthebest
and if they don't know about it, they should learn, cause it's everywhere and always will be
SamWhited
I mean, I say "I assume they meant emphasis", it's not even something you'd think about reading that. It just parses fine.
pep.
SamWhited, so what if I use /foo/ now and it's interpreted as an emphase when in fact I'm writing IPA
lskdjfhas joined
dwdhas left
pep.
If you want concrete examples
SamWhited
I'm reasonably sure most people won't write IPA, or regular expressions, or anything else where the conflict will matter.
sonnyhas joined
Link Mauve
moparisthebest, haha, you wish.
SamWhited
Even if it did, okay, your IPA might be italics on some clients. It doesn't break it though.
dwdhas left
SamWhited
That seems like a tiny edge case to me.
pep.
The point of a client is not to "not break"
pep.
"Ah I'm fine it barely works!"
Link Mauve
SamWhited, I know a room where people have been sending a lot of IPA over the years.
Link Mauve
(It’s about linguistics.)
pep.
Anyway, have to go
moparisthebest
pep., but it doesn't break anything including regex cause all characters are there
Link Mauve
moparisthebest, it just looks bad, while it could have been avoided altogether by simply separating formatting from input.
moparisthebest
I don't think so it's just a natural way to add emphasis without a huge WYSIWYG editor
moparisthebest
I don't have room for one of those on my phone screen
dwdhas left
Link Mauve
And remember that it’s the way Gajim misguidedly did it, think about a random dev throwing that at their Markdown library which would strip any such character as soon as it is parsed, which would replace unescaped snake_case_words with italic in the middle of variable names, etc.
archas left
archas joined
dwdhas left
SamWhited
I'm sure you do know a room about that, but that room is also a tiny edge case and it's a tiny edge case that's not even broken
Archas joined
Link Mauve
moparisthebest, if your client considers it the natural way to add emphasis, that’s fine, it should just both expose the formatted one and the plain text one properly.
sonnyhas joined
Link Mauve
And that way you also see that it oops transformed that variable name in snakecaseword, and can edit your message to fix it.
Archas left
Link Mauve
SamWhited, for now, just wait until clients start using Markdown instead.
SamWhited
Yah sure, but that's a different issue. We should absolutely provide guidance and try to make sure that the easiest way to do it is also a good UX.
Ge0rG
Function names, path names and enumerations are in my experience the things most often misidentified by xmpp clients. Enumerations like (a)
Link Mauve
Bbl Rust meetup! \o_
dwdhas left
Link Mauve
moparisthebest, SamWhited, I would totally welcome a XEP describing guidelines for input markup, to tell how clients could treat input to transform it into XHTML-IM or succ(XHTML-IM), just sending it as-is on the wire is a no-go.
dwdhas left
SamWhited
I disagree, translating it into XHTML-IM is a terrible idea.
sonnyhas joined
SamWhited
I don't know if translating to succ(XHTML-IM) is a good idea or not, of course, since it doesn't exist yet.
Link Mauve
I’ll send an email to the list later, in the meantime I’m going to be late for a Rust pizza. :)
dwdhas left
Ge0rG
This subject is really bringing up emotions...
dwdhas left
Steve Killehas joined
dwdhas left
tuxhas joined
dwdhas left
dwdhas left
valohas joined
dwdhas left
dwdhas left
sonnyhas left
sonnyhas joined
dwdhas left
dwdhas left
dwdhas left
Steve Killehas left
Valerianhas left
Valerianhas joined
dwdhas left
vanitasvitaehas left
dwdhas left
dwdhas left
ralphmhas left
dwdhas left
dwdhas left
dwdhas left
sonnyhas left
sonnyhas joined
sonnyhas left
Valerianhas left
sonnyhas joined
dwdhas left
dwdhas left
emxphas joined
sonnyhas joined
sonnyhas joined
dwdhas left
sonnyhas left
sonnyhas joined
lskdjfhas left
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
daniel
Ge0rG: it's not very technical. So everyone has an opinion
Ge0rG
daniel: and I'm getting less and less sure what my opinion is.
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
dwdhas left
sonnyhas left
sonnyhas joined
jjrhhas left
sonnyhas joined
sonnyhas joined
dwdhas left
jonasw
great, I missed the party
stefandxmhas joined
sonnyhas left
sonnyhas joined
sonnyhas joined
sonnyhas joined
Valerianhas joined
dwdhas left
jjrhhas left
dwdhas left
jjrhhas left
sonnyhas left
dwdhas left
dwdhas left
sonnyhas joined
dwdhas left
dwdhas left
dwdhas left
dwdhas left
Tobiashas joined
stefandxmhas left
dwdhas left
dwdhas left
danielhas left
danielhas joined
ralphmhas joined
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
alacerhas joined
goffihas left
dwdhas left
archas left
archas joined
dwdhas left
dwdhas left
jonasw
so, I’d like to add a few bits
dwdhas left
jonasw
moparisthebest, re differences between body/non-body: yes, that’s a problem in some cases. I’m not sure how to fix that. However, I’d argue that if you’re doing transactions like that only over unsigned XMPP, you may be doing something wrong.
jonasw
(same thing holds for email)
jonasw
moparisthebest, re "/me", which is in body: funny thing about that. Pidgin hat a vulnerability where messages starting with /me would not be encrypted with OTR. That’s what you get from adding interesting semantics to body parts (pun not intended).
moparisthebest
yea email suffers from the same, probably other things
jonasw
otherwise, I tend to agree with Link Mauve, except that HTML email is an abomination which should be killed with fire.
moparisthebest
why would the sending side ever process that at all?
jonasw
SamWhited, I’ve seen people ask me what I mean with the underscores in "_foo_".
SamWhited
I don't see how that Pidgin bug is relavant; if we're going to argue for that being a reason never to interpret text in body then shouldn't we never put text outside the body because it's never encrypted because OTR only encrypts the body?
moparisthebest
isn't /me and what I'm talking about a 100% reciever feature?
jonasw
SamWhited, I just wanted to throw in the fun fact :)
jonasw
moparisthebest, yes, pidgin is broken
moparisthebest
anyway the biggest argument might be about fragmentation
jonasw
it uses /foo for commands, and I bet they implemented /me as "send the text behind /me with '/me' as prefix", circumventing the layers which added encryption.
moparisthebest
putting text in body makes it *just work* in all clients whether they make it fancy or not
dwdhas left
ralphmhas left
jonasw
moparisthebest, now of course we can’t stop make people type things like *just work* in body (I’m with Link Mauve on that that we might want to specify how that’s supposed to work), but this shouldn’t be used as transport
jonasw
because it is not extensible, and most markups only have limited features, and at some point things become not-so-readable in plaintext.
jonasw
and yes, much of this may not matter for the typical IM user sending things, but it matters for automated services such as Flows bridge or bots sending high-density content which simply needs formatting to be easily parsable
jonasw
we need a format for that, and if we’re going to have a markup format in XMPP, it should work everywhere in XMPP..
SouLhas left
moparisthebest
I know this is xmpp and such and I might get fried for saying this
moparisthebest
but not everything needs to be extensible
dwdhas left
jonasw
(this is, again, for transport only. I’m not at all arguing that people shouldn’t be able to type *foo* and have it come up as emphasised, but the transport shouldn’t convey "*foo*" in that case)
SamWhited
I was about to write that. I'm not convinced the markup needs to be (I'm not convinced it shouldn't be either, mind)
moparisthebest
I think the sender shouldn't do any processing at all
moparisthebest
and reciever decides if it wants to emphasize stuff or not
moparisthebest
now also I'm only talking about the IM usecase
jonasw
only the sender can possibly know which semantics and styling was intended. trying to recover that at the receiver is going to be a mess.
SamWhitedhas left
moparisthebest
I think the microblogging use-case is entirely seperate and needs a seperate XEP and such
jonasw
yes, I’m with you on the IM usecase -- just not only IM between humans. also machines and humans, which is still IM.
jonasw
I’m not talking about microblogging.
moparisthebest
I don't think you want or need complicated markup in IM
jonasw
sure, the receiver can decide to strip all markup, and we totally should encourage implementations to allow that.
dwdhas left
jonasw
I don’t want to be able to write it, but I want to be able to receive it. Yes, (and I’m going to be killed for that), this includes headings.
moparisthebest
does anyone enjoy MIRC colors for instance
jonasw
colors are tricky -- I made a proposal how to make them right.
jonasw
(actually colors and fonts are the reason I ban XHTML-Im in my clients, and I totally think that succ(XHTML-IM) should not support arbitrary colors and fonts.)
jonasw
what I think it sohuld support I already mentioned on the ML:
Non-semantic things:
- Colorise things with colors from a palette (e.g. 360 colors from the
XEP-0392 palette) (via Georg Lukas)
Semantic things:
- Emphasis (typically italics), Strong (typically boldface)
- Pre-formatted text (code), including a way to specify the language (this may
make the colorisation of things obsolete, the only use-case I’ve heard so far
is syntax-highlighting)
- Blockquotes
- Paragraphs
- Enumerations and unordered lists
- Links (but possibly without the possibility to change the text shown), with
a whitelist of URL schemas
Other things which may be useful, but I’m not sure if we don’t have better
ways to do that by now:
- Embedding multimedia content, like images, audio, video (a SIMS-message may
be better suited for that)
moparisthebest
I think it should only support *bold* and /italics/ and _underline_ and, oh look, gajim and most other things already do, problem solved
dwdhas left
waqashas joined
moparisthebest
everything else is just regular text
jonasw
moparisthebest, sure, I’m fine if clients support that as input.
jonasw
but those "trivial" markups get complicated as heck in not-so-trivial situations like words which include one or more the meta-characters
jonasw
or sentences which happen to include them twice
moparisthebest
I think this is a solution in search of a problem
jonasw
I laid out use-cases on the ML.
Ge0rG
moparisthebest: when you enter that in gajim, can you see the markup?
zinid
tl;dr: have you decided yet what markup to use?
jonasw
zinid, no.
jonasw
zinid, you’re a server dev, you must look away :P
zinid
ok :D
moparisthebest
Ge0rG, what markup?
Ge0rG
Actually, the server should be able to convert the markup from one client format to the other
moparisthebest
I just have a box to type in in gajim
zinid
jonasw: yeah, nobody is asking server devs nowadays :)
dwdhas left
Ge0rG
moparisthebest: my problem with adhoc pseudo markdown is lack of interop
moparisthebest
Ge0rG, except it works with or without processing equally
Ge0rG
Anyway, gotta run now. CU tomorrow
jonasw
it doesn’t
moparisthebest
so free perpetual interop
jonasw
in the cases I mentioned abve
jonasw
if it fails at the only thing it’s supposed to do, it doesn’t work.
moparisthebest
where does it fail?
zinid
I don't think a server can modify body due to e2ee
jonasw
zinid, tips hat, that’s a well-placed troll.
jonasw
moparisthebest, sentences which happen to contain multiple meta-characters which happen to have some special meaning despite that meaning not being intended.
jonasw
as an example
moparisthebest
jonasw, and something is bolded erroneously, and no one cares?
moparisthebest
what am I missing
jonasw
yes but that’s really the only thing this is supposed to do.
moparisthebest
it's perfectly fine
jonasw
conveying semantics by bold/italics/underline/whatever. it literally fails to do its sole purpose.
Ge0rG
moparisthebest: I wrote earlier that some clients replace (a), (b), (c) style enumerations with smileys
jubalhhas joined
jonasw
also, tell my mother how to make a word containing an "*" italics/bold with Markdown.
moparisthebest
if I say the regex is .*bob.* and that ends up being bolded, you still get the message
jonasw
Ge0rG, go and kill pidgin with fire already.
dwdhas left
Ge0rG
moparisthebest: no, because I can't copy paste that regex any more
and no it doesn’t matter when a thing invented to do only exactly one thign literally doesn’t do that thing.✎
jonasw
and no it does matter when a thing invented to do only exactly one thign literally doesn’t do that thing. ✏
Ge0rG
I'm an experienced user of markdown and I regularly fail to quote a formula with two multiplication signs.
moparisthebest
I disagree, it still conveys the same meaning whether it's highlighted or not
SamWhited
*this is bold* and so is **Trainer*Innen**, maybe? Just a thought (actual character doesn't matter obviously)
jonasw
SamWhited, sure, but this is the point where you don’t want humans to write that.
dwdhas left
jonasw
that’s also exactly the kind of thing I meant by "not extensible". You’d normally have to bump namespaces for this type of change.
jonasw
we can’t do that if we put things in <body/>.
moparisthebest
it's not a problem that needs solved
SamWhited
Yah, fair, it's really not
jonasw
moparisthebest, also, pandoc would highlight the first part and leave the second unhighlighted.
moparisthebest
you don't need a spec or standard that solves every single edge case ever
moparisthebest
that's also fine, gajim highlights nothing
jonasw
moparisthebest, but it’s comparatively easy to do so!
moparisthebest
I guess if you give me a huge editor with a ton of buttons maybe
moparisthebest
I don't want that, I'll just type *trainer*innen* anyway
moparisthebest
how does the sending client even know what I mean
jonasw
you’re free to have a client which supprots that type of input (I’m going to write one, for sure). But that’s not what should be in the transport.
moparisthebest
then you run into UI issues and such
jonasw
the sending client can offer you neat in-line markdown preview support.
moparisthebest
I have limited space on my phone screen as it is
Valerianhas left
jonasw
I’m thinking like some tools do auto-completion. I can’t describe that in just one line, but the flow is amazing.
Ge0rG
With LMC you just retry multiple times to fix the markup you never wanted, giving up in frustration after the fifth attempt
jonasw
you really care to add any kidn of markup on the phone? I’d be too lazy to search for "*".
moparisthebest
basically that, then I'd have to try to get it to look right
SamWhited
FWIW, if I ever were to release one of my toy clients it would have something like the toolbar in this in it: https://simplemde.com/
moparisthebest
where as if you display what I send exactly, and maybe bold/italic/underline part, it's fine
dwdhas left
jonasw
SamWhited, looks great
SamWhited
Maybe not with markdown, but something similar.
SamWhited
It's just a pleasant experience; I type **, my mother hits the "B" button. It all works out in the end.
jonasw
SamWhited, I was more thinking like:
1. You type *foo*
2. Client makes "foo" boldfaced and removes the asterisks.
3. You find that you didn’t want *foo* boldfaced, so you type backspace.
4. Client changes back to *foo*, but does not delete the *.
5. You can continue to type as normal.
jonasw
(in addition to a lightweight formatting toolbar)
jonasw
(of course, turning off any kind of formatting would work too. and stuff pasted from clipboard would never get formatted automatically.)
moparisthebest
or, you just type *foo*, recieving client may or may not bold it, everyone is happy, far less work, 100% interoperable
jonasw
moparisthebest, if everybody sees different things that’s not interoperable.
jonasw
that’s "it works"
moparisthebest
it's different regardless
jonasw
but not "it’s interoperable and works great"
moparisthebest
I typed this in courier new and you are seeing arial, maybe
SamWhited
Yah, Jira does the backspace thing and it never works as expected. I'm unsure why though.
moparisthebest
maybe we should start sending fonts and DPI values over xmpp too then?
jonasw
SamWhited, hm. I’d put some effort to make it work, if you care to test at some point? :)
SamWhited
Sure
jonasw
moparisthebest, of course not.
jonasw
SamWhited, also, you can then try to exploit my webview-based message view :)
SamWhited
I am always game for that.
jonasw
moparisthebest, in fact, killing off any kind of font change support is one of the reasons why I’m in favour of obliterating @style in XHTML-IM or obliterating XHTML-Im altogether.
jonasw
but I don’t have XHTML-IM support yet, so ;-)
moparisthebest
I just don't buy the argument that me seeing *foo* without bold and you seeing *foo* bold is any sort of problem at all
jonasw
I’ll put the accessibility argument back in the ring.
jonasw
those asterisks and underlines are annoying for a11y software.
jonasw
and slashes etc.
dwdhas left
SamWhited
If you didn't click it, also click the little eye icon in that web editor. It's the best part.
jonasw
SamWhited, :)
jonasw
much of this would be overkill for day-to-day IM use. but I definitely can see use-cases.
jonasw
and again, I think if we have these use-cases, I see no reason to have three different types of markup in XMPP if we can simply use the same thing for every use-case in the transport.
SamWhited
I don't think we can. Someone will always want a full blown layout engine for blogs. IM on the other hand just needs basic styling.
moparisthebest
jonasw, a11y software presumably would ignore those strange characters, I don't really know
jonasw
moparisthebest, I happen to know a few people who use a11y software.
moparisthebest
what does it say when it gets to *foo* or "bolded foo"
jonasw
SamWhited, I tend to agree that we might need some XHTML (but more than just the IM subset we had) for blogging cases.
jonasw
but for IM, I see something like XHTML-IM + possibly A/V embedding minus the @style as useful.
jonasw
moparisthebest, bolded "foo" leads to emphasis
jonasw
the other thing depends on the implementation
jonasw
but some will read out "asterisk foo asterisk"
moparisthebest
what kind of emphasis?
jonasw
tonal
moparisthebest
I'm not sure what you mean
moparisthebest
like it screams at you?
jonasw
no, but like you would emphasize a word in a sentence. the whole point you use emphasis.
moparisthebest
so I think my argument holds and is the same
moparisthebest
someone who uses that software, depending on their client, would hear 'star foo star' or FOO with emphasis
jonasw
I don’t think so?
moparisthebest
and either way get the same meaning
jonasw
no
jonasw
they would get "asterisk foo asterisk" with spoken emphasis.
jonasw
(if the client boldfaces the "*foo*")
moparisthebest
still they know what that means
moparisthebest
same as you or I know what it means when we read it
jonasw
that’s bad accessibility.
jonasw
really.
jonasw
that’s the type of thing people dependent on a11y software switch softwares for.
moparisthebest
it's identical to your plan of the sending client guessing all these things
jonasw
no
jonasw
the sender can revise and make sure it actually reflects their intentions.
jonasw
they can’t do that on the receiving side.
moparisthebest
but no their software would either say "asterisk foo asterisk" or "foo" with emphasis
moparisthebest
either way they understand, no problems
jonasw
why would they omit the asterisks if the client has them in the text view?
jonasw
they understand, but it wastes time.
SamWhited
Yah, that sounds bad. Accessibility is definitely the thing I'm most concerned about if we were to recommend something like this. Maybe I'll see what androids reader does later.
moparisthebest
now I'm curious how does a11y software read xhtml-im
moparisthebest
it would have to be way worse
jonasw
no
jonasw
they read it like they read webpages
jonasw
for which they are basically optimised
jonasw
(you do realize that a11y software scrapes the widgets of applications, don’t you?)
moparisthebest
BLUE FONT BLACK BACKROUND BOLD MARQUEE FOO
jonasw
(of course, applications help with that via a11y APIs and such)
dwdhas left
dwdhas left
ralphmhas left
Valerianhas joined
dwdhas left
dwdhas left
dwdhas left
stefandxmhas joined
dwdhas left
jubalhhas joined
Valerianhas left
dwdhas left
Valerianhas joined
dwdhas left
archas left
ralphmhas left
dwdhas left
Syndacehas joined
stefandxmhas left
archas joined
ralphmhas joined
uchas joined
dwdhas left
dwdhas left
uchas joined
dwdhas left
dwdhas left
dwdhas left
ralphmhas left
moparisthebesthas joined
dwdhas left
uchas joined
dwdhas left
jonaswhas left
dwdhas left
valohas joined
dwdhas left
jubalhhas joined
la|r|mahas left
ralphmhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
archas left
archas joined
dwdhas left
dwdhas left
zinidhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
ralphmhas left
dwdhas left
jerehas joined
jerehas joined
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
jerehas left
jerehas joined
dwdhas left
dwdhas left
danielhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
lskdjfhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
jubalhhas joined
jubalhhas left
dwdhas left
dwdhas left
Guushas left
valohas left
dwdhas left
dwdhas left
Guushas joined
dwdhas left
dwdhas left
dwdhas left
stefandxmhas joined
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
SamWhitedhas left
dwdhas left
dwdhas left
Valerianhas left
dwdhas left
dwdhas left
dwdhas left
uchas joined
dwdhas left
dwdhas left
dwdhas left
Valerianhas joined
Archas joined
jjrhhas left
dwdhas left
uchas joined
Link Mauve
jonasw, not supporting font-family, color or color-background in @style is fine, but not supporting @style altogether is a bit bad imo.
dwdhas left
Link Mauve
And it’s trivial to parse and whitelist correctly.
dwdhas left
Link Mauve
“21:09:44 SamWhited> I don't think we can. Someone will always want a full blown layout engine for blogs. IM on the other hand just needs basic styling.”, that’s why I’ve been proposing to extend XHTML-IM with other profiles in the past, maybe I should go forward with that.
Link Mauve
Not only for microblogging, which wasn’t even my use-case back then.
Alexhas left
Link Mauve
“21:10:57 jonasw> but for IM, I see something like XHTML-IM + possibly A/V embedding minus the @style as useful.”, @style is definitely useful, amongst the real-world examples of colour being used properly I’ve seen over the years were titles which include colour, sending a big red heart to someone, rainbows, spoilers, and in general style effects.
Link Mauve
You can argue that we all have to be professional in our communications and all, but being able to do playful things is also useful.
Link Mauve
That’s why I would dislike to see @style disappear altogether, whether in XHTML-IM or in a next spec.
Link Mauve
Not all of us are sad grown-ups. :)
dwdhas left
dwdhas left
jjrhhas left
Zash
<style color='rainbow'>hello</style>
jerehas joined
Zash
And you seem to forget that using color in IRC is a crime against humanity and only annoying trolls and spammers use it
Link Mauve
Zash, currently we’re using span@style for that, per-letter, it works well and allows as much or as little control as you want.
dwdhas left
Link Mauve
Zash, I’m actually enjoying when IRC people send spoilers in spoiler-style, and biboumi renders them as wanted.
dwdhas left
jjrhhas left
waqashas left
SamWhited
I'm sure someone will need a layout engine, but that thing needs to not be XHTML-IM.
SamWhited
We need to figure out how to create something that won't end up with such an abysmal security record.
SamWhited
Extending the broken thing we have won't make that better.
Link Mauve
SamWhited, I once wrote a web implementation of XHTML-IM, approximately on the same model as poezio’s, and due to that I’m quite certain it didn’t have any kind of security issue.
SamWhited
Good for you, it would be the first I've ever seen.
SamWhited
As always, I'm not saying it's impossible (it's not). But most people aren't going to do it right the first time.
Link Mauve
That argument that it’s broken by definition is quite dubious.
Link Mauve
SamWhited, we need better security guidelines, two days ago I reviewed the current ones and they are abysmal.
SamWhited
Obviously, I disagree. The only way to have any inkling of security is to make the default secure and make it require work for developers to screw it up, not make the default broken and make it require work to fix.
SamWhited
I agree the current ones are terrible and could be improved, but it won't fix anything.
dwdhas left
Link Mauve
You just discarded any web client here.
SamWhited
(although we should do it either way, hopefully it will help at least a little bit)
Link Mauve
The defaults of these APIs is to be insecure.
SamWhited
Yes, but unfortunately I can't change that spec.
Link Mauve
XHTML-IM isn’t any more or less insecure than RFC6121 here.
SamWhited
If we could deprecate the web I assure you, I'd be all over it, but this arguent isn't about the web. It's about how we interop with it.
Link Mauve
(Yes, I’ve seen implementations shove <{jabber:client}body/> into the DOM.)
Link Mauve
SamWhited, sure.
Link Mauve
It’s just a bogus argument because as a web dev you have to code extremely defensively all the time.
SamWhited
Sure, you should, but I don't see what that has to do with anything
SamWhited
But sure, for the sake of argument let's ignore the people that will do the obviously wrong and broken thing
SamWhited
Let's talk about the people who will try to do it right, and will implement the whitelist and be careful about elements and attributes
Zash
I'm not convinced we can make the web not be broken by default
SamWhited
Any tiny logic bug in the XHTML-IM whitelist implementation leads to a critical issue. It doesn't matter how good you are, you will make mistakes.
SamWhited
We can make something where any trivial mistake isn't a critical security issue.
Link Mauve
You’re saying that argument in loop, that people will do the broken way by not reading the spec, and then that it isn’t their fault and we should make a spec that can’t be gotten wrong, but then all specs will be gotten wrong by people who don’t read them, and the loop is looped.
SamWhited
I am not saying anything of the sort
SamWhited
Of course you can always get something wrong, you can always introduce security issues, etc.
Link Mauve
SamWhited, implementing XHTML-IM by a simple whitelist is imo not the correct way to go, see poezio’s implementation (sadly that web implementation I did was proprietary, and AFAIK never deployed publicly).
SamWhited
I'm saying *we* should be writing specs defesivesly, not relying that web devs will develop defensively, or that they will never make any mistakes.
SamWhited
Link Mauve: I agree, that is the correct way to go.
Link Mauve
SamWhited, we can’t make any spec if the goal is to make web devs develop non-defensively.
SamWhited
That's also not what I said
Link Mauve
Zash, same. :(
SamWhited
I said we shouldn't be *relying* on the fact that web devs will code defensively and make no mistakes.
SamWhited
Everyone has to be defensive, including us. We can't just assume the burden lies entirely on the application developer.
Link Mauve
Right, by providing them tested implementations, by providing them clear security guidelines, by encouraging them to do the correct thing.
Link Mauve
Not by rewriting what works into something which works less well already.
Link Mauve
SamWhited, sure.
SamWhited
That's not good enough. I'm not disagreeing, by all means, improve the security considerations, that would be great, but it's not going to help in any significant fashion.
SamWhited
We need something where the default isn't broken and where every mistake isn't an issue.
Link Mauve
I disagree on that.
Link Mauve
You can’t have a non-broken default on the web.
dwdhas left
Link Mauve
It’s just impossible.
Link Mauve
Because it’s broken by design.
dwdhas left
SamWhited
Sure you can, a number of techniques have been discussed.
Link Mauve
What we currently have works, has no intrinsic security issue, can be implemented securely (by us if any), and we should encourage that instead of replacing it with something with exactly the same potential security issues.
SamWhited
Please read the mailing list thread, we're literally just reiterating the exact same things that have been said on it.
Link Mauve
I have read it entirely already.
Link Mauve
And no matter what you replace it with, div.innerHTML = parse_markdown(message.body); will exist.
SamWhited
Why do you think we would encourage replacing it with something with the exact same issues?
SamWhited
What does that have to do with anything? Yes, we can't stop people from doing non-standard and broken things with the body, that has nothing do with deprecating XHTML-IM though.
Link Mauve
Deprecating XHTML-IM means people will find other ways to do formatting, the discussion we had earlier has terrifying examples of that.
Link Mauve
And replacing XHTML-IM (and subsequently deprecating it) has exactly the same issues as XHTML-IM has currently.
mathieui
SamWhited, because deprecating XHTML-IM without a replacement is something I am not looking upon favorably; and any replacement still has the exact same kind of issues you want to avoid
SamWhited
No, again, read the list, there have been multiple suggestions that do not have the exact same kind of issues.
Link Mauve
I have, and they all have them, even the JSON-based protocol break solution has them, if you don’t sanitise your input properly.