XSF Discussion - 2017-10-19

jonasw, no worries

I hope that Link Mauve eventually reconsiders his vote, because maybe he was also on the wrong track about what BMH is about…

Flow: I don't think so

Flow, to be honest, I think you picked a really bad time for this

the worst imaginable

I now understand your use-case, but in light of the XHTML-IM obsoletion discussion ...

I had that thought as well

And I said that on the ML already

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.

If the XSF wants to avoid flawed implementations BTW (seeing the xhtml-im thread), I suggest we start here

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.

blaming the people who switch to Discourse is in any case the right thing to do

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

(I’m not sarcastic here :))

Like I said earlier, I blame the web.

blaming the web wfm too :)

yeah, everyting was better when we still had gopher

Flow: A very clear problem statement in the introduction probably helps.

gopher was amazing

I never used it, but everything *was* better

what's wrong with discourse?

I wrote a gopher server once, in freepascal.

then firefox dropped gopher support :(

I looked into the specs and almost started implementing it in Prosody :)

can't we just go back to NNTP?

NNTP over NTP

From what I gather, NNTP was perfection.

NNTP was quite good indeed

Zash: except for the spam.

it’s always the spam

Not quite clear on the distinction between NNTP, Newsgroups and usenet.

Oh wait. XMPP is the NNTP of the 2000s.

Zash: similar to the distinction between XMPP and Jabber.

XMPP, Jabber, conversations.im?

It was pure perfection anyways. Therefor it must die.

The Web will win and consume the world, because it is terrible.

Can't have nice things.

Worse is better.

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.

https://twitter.com/saghul/status/920934733147787264

Real-Time Communications dev-room: deadline 23:59 UTC on 30th of November.

Ge0rG: you mean there are Android devices with a special storage area for malware?

tux: no, it's more of a trojan horse when you sell your android device.

👍

tux: after a factory reset, the device can only be unlocked with the gmail account that was used on it before resetting.

Effectively opening a market for Gmail account data.

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

Link Mauve, k, thanks. I wonder if at least OOB should be mentioned in https://xmpp.org/extensions/xep-0387.html#im

I doubt so, it’s one of these XEPs that should be deprecated imo, it brings pretty much no information.

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.

what was SIMS again?

Flow: Slightly more advanced OOB, I think. I need to read both again and compare.

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.

Eg. allows for multiple media types.

Flow, 0385.

Flow: Stateless Inline Media Sharing

Link Mauve, how do you image a plain text version of CommonMark look like?

Basically, a description of the file, with metadata, and multiple possible sources to retrieve it.

Flow, for example “this is **bold**” into “this is bold”.

That way the receiver won’t have to understand CommonMark to understand a sentence.

so I need to converters and loose stylistic/semantic information if the recipient can only look at the body?

Do we also convert lists?

Right, that’s the definition of plain text.

And headings?

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.

And why would I convert at all? CommonMark is nicely readable as plain text

Here, renumbering them into 1. 2. 3.

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?

Flow, it’s not always, I just gave you two examples.

Messing with the message the user sent seems like a bad idea, especially when it's already perfectly readable plain tex.t

gajim, all IRC clients, most email clients, they all do that

Link Mauve, that's a corner case, and I believe you will get normalized CommonMark out of Discourse

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

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.

due to legacy sure, but it works great and everyone understands it

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?

what flow just did, /me, is that a XEP someplace or is that convention?

Flow, same. ^^

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.

*form of

moparisthebest: consistency of user experience, fracturing of the ecosystem and complexity of supporting possibly numerous markups

moparisthebest: https://xmpp.org/extensions/xep-0245.html

yea, and gajim bolded that for me as well, equally I would have understood if it didn't

I'm on the phone now

so hard to go into details

Flow: You didn't see the thing where some Mozilla person wanted to remove plain text because it didn't have tracking images?

ah nifty SamWhited , also just in body, and if the client didn't support it it'd still be mostly readable

Zash, I read about it :)

bbl

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

publishing blog posts is a different use-case with different needs

Formatting vs semantics again

moparisthebest, that’s a Gajim bug, not something we should encourage.

(Bolding something.)

don't many other clients do the same?

seems like it should be a feature we should encourage to me

moparisthebest, I’ve never seen any other client, and it sounds misguided at best.

it's at minimum in basically every irc client and most email clients

surely it's in other xmpp clients

I agree with Link Mauve, that's not something that should be encouraged. Or at best gajim could translate that to xhtml-im

my point is it's readable whether the client special-cases it or not

no fragmenting or confusion

I disagree, it's simple, effective, and a very nice experience. We should absolutely encourage it.

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/

Also if a client translates that, how do I write IPA now? :(

(or we should absolutely encourage something similar, I'm not advocating for exactly what Gajim does, whatever that may be)

(I just reported that bug to Gajim, fyi.)

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.

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>

pep., but then evil alice can send 1 message with something different in <body> and <somefancymarkup>, it opens up a bad can of worms

pep., won't they understand _bar_ or /baz/ , and if not, why exactly does it matter?

because I want to express something if I use that?

by the way I'm using gajim now and it still *shows* all the characters, just additionally underlines/bolds/italics them

I want their client to convey it for me, they know what italic is, what bold it, they might not know what **, __, or // are

Or whatever other markup you fancy

here's the other thing, I don't want to read your fancy markup, so I can turn it off on my client

if your client sends it in <newfancymarkup> then I have to view that

I don't have an option not to see it

moparisthebest, err, Markdown isn’t plain text, it just isn’t. ✏

it is though, it's made to be perfectly readable as plain text

and maybe parts are a bit questionable but that's fine, we only want the super simple obvious parts

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.

except markdown is plain text

or at least the subset that every chat program has been happy with for years

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.

no, that's the entire point

moparisthebest, Markdown is a superset of HTML.

you don't use a lib to send anything

moparisthebest, markdown is not plaintext. If you say that I say we should use escaped XML as markup language

It’s not plain text, has never been.

<strong>Hey!</strong>

you send the exact text the user writes

the recieving client displays it, optionally with a bit of formatting

here I'll send a screenshot of what gajim displays so we are all on the same page *bold* _underlined_ /italic/

moparisthebest, so how do you interpret what pep. just sent?

moparisthebest, ah, but *bold* is actually italic in Markdown.

Now what do you do?

I interpret it as, why the hell is he writing xml in a text chat

While what pep. wrote is actually bold in Markdown.

moparisthebest, but that’s Markdown he just wrote.

I did write markdown indeed.

Not XML.

Are you rehashing all the same things?

Zash, yes, because nobody understands apparently

Zash, seems so. :/

https://burtrum.org/up/30079903-aaa9-43c1-b08f-2642b7e7764d/open-screeny-23190.png

see no information is lost, all characters are displayed

moparisthebest, except it looks bad.

and it's readable with and without fancy parsing

then turn it off, or make your client display it differently for you

*But* this _is_ not what I /meant/, at ~all~. < I'm just sending plaintext, this is not markup.

that's fine, I still saw everything

How does your client deal with that now

pep., https://burtrum.org/up/5eebca0a-a420-494c-816b-b0907998107b/open-screeny-23265.png

moparisthebest, I know exactly how it rendered it, that doesn't reflect at all what I wanted

having a WYSIWYG editor wouldn't have done a better job

and would be terrible

That's the issue when you don't separate <body> and $markup

pep.: You should have included a body hint saying text/plain

:)

Zash, ah, too bad ✏

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.

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

and a million other things

How does that not reflect what you wanted?

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?

How does gajim deal with both *foo*

(or italics, or whatever)

pep., you mean this and *that*? :)

SamWhited, because that could be interpreted as an emphasis, which I didn't want

Link Mauve, no I meant both at the same time

moparisthebest: same with email and xhtml-im and everything

then you shouldn't have used the characters that have meant emphasis for 20+ years pep.

I’d suppose it displays it normally-bolded.

pep. what did you want then? Even if there is no bolding or highlighting, *this* looks like emphasis to me.

and to everyone else

that's why everyone uses them

SamWhited, moparisthebest, that's the magic of having markup separated from plaintext

I didn't understand that.

I used ** but it could have been __ or ^^ for all I care

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.

I highly doubt that

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

I think you send anyone something like *this* it's pretty apparant

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.

and if they don't know about it, they should learn, cause it's everywhere and always will be

I mean, I say "I assume they meant emphasis", it's not even something you'd think about reading that. It just parses fine.

SamWhited, so what if I use /foo/ now and it's interpreted as an emphase when in fact I'm writing IPA

If you want concrete examples

I'm reasonably sure most people won't write IPA, or regular expressions, or anything else where the conflict will matter.

moparisthebest, haha, you wish.

Even if it did, okay, your IPA might be italics on some clients. It doesn't break it though.

That seems like a tiny edge case to me.

The point of a client is not to "not break"

"Ah I'm fine it barely works!"

SamWhited, I know a room where people have been sending a lot of IPA over the years.

(It’s about linguistics.)

Anyway, have to go

pep., but it doesn't break anything including regex cause all characters are there

moparisthebest, it just looks bad, while it could have been avoided altogether by simply separating formatting from input.

I don't think so it's just a natural way to add emphasis without a huge WYSIWYG editor

I don't have room for one of those on my phone screen

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.

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

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.

And that way you also see that it oops transformed that variable name in snakecaseword, and can edit your message to fix it.

SamWhited, for now, just wait until clients start using Markdown instead.

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.

Function names, path names and enumerations are in my experience the things most often misidentified by xmpp clients. Enumerations like (a)

Bbl Rust meetup! \o_

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.

I disagree, translating it into XHTML-IM is a terrible idea.

I don't know if translating to succ(XHTML-IM) is a good idea or not, of course, since it doesn't exist yet.

I’ll send an email to the list later, in the meantime I’m going to be late for a Rust pizza. :)

This subject is really bringing up emotions...

Ge0rG: it's not very technical. So everyone has an opinion

daniel: and I'm getting less and less sure what my opinion is.

great, I missed the party

so, I’d like to add a few bits

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.

(same thing holds for email)

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

yea email suffers from the same, probably other things

otherwise, I tend to agree with Link Mauve, except that HTML email is an abomination which should be killed with fire.

why would the sending side ever process that at all?

SamWhited, I’ve seen people ask me what I mean with the underscores in "_foo_".

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?

isn't /me and what I'm talking about a 100% reciever feature?

SamWhited, I just wanted to throw in the fun fact :)

moparisthebest, yes, pidgin is broken

anyway the biggest argument might be about fragmentation

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.

putting text in body makes it *just work* in all clients whether they make it fancy or not

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

because it is not extensible, and most markups only have limited features, and at some point things become not-so-readable in plaintext.

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

we need a format for that, and if we’re going to have a markup format in XMPP, it should work everywhere in XMPP..

I know this is xmpp and such and I might get fried for saying this

but not everything needs to be extensible

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

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)

I think the sender shouldn't do any processing at all

and reciever decides if it wants to emphasize stuff or not

now also I'm only talking about the IM usecase

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.

I think the microblogging use-case is entirely seperate and needs a seperate XEP and such

yes, I’m with you on the IM usecase -- just not only IM between humans. also machines and humans, which is still IM.

I’m not talking about microblogging.

I don't think you want or need complicated markup in IM

sure, the receiver can decide to strip all markup, and we totally should encourage implementations to allow that.

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.

does anyone enjoy MIRC colors for instance

colors are tricky -- I made a proposal how to make them right.

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

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)

I think it should only support *bold* and /italics/ and _underline_ and, oh look, gajim and most other things already do, problem solved

everything else is just regular text

moparisthebest, sure, I’m fine if clients support that as input.

but those "trivial" markups get complicated as heck in not-so-trivial situations like words which include one or more the meta-characters

or sentences which happen to include them twice

I think this is a solution in search of a problem

I laid out use-cases on the ML.

moparisthebest: when you enter that in gajim, can you see the markup?

tl;dr: have you decided yet what markup to use?

zinid, no.

zinid, you’re a server dev, you must look away :P

ok :D

Ge0rG, what markup?

Actually, the server should be able to convert the markup from one client format to the other

I just have a box to type in in gajim

jonasw: yeah, nobody is asking server devs nowadays :)

moparisthebest: my problem with adhoc pseudo markdown is lack of interop

Ge0rG, except it works with or without processing equally

Anyway, gotta run now. CU tomorrow

it doesn’t

so free perpetual interop

in the cases I mentioned abve

if it fails at the only thing it’s supposed to do, it doesn’t work.

where does it fail?

I don't think a server can modify body due to e2ee

zinid, tips hat, that’s a well-placed troll.

moparisthebest, sentences which happen to contain multiple meta-characters which happen to have some special meaning despite that meaning not being intended.

as an example

jonasw, and something is bolded erroneously, and no one cares?

what am I missing

yes but that’s really the only thing this is supposed to do.

it's perfectly fine

conveying semantics by bold/italics/underline/whatever. it literally fails to do its sole purpose.

moparisthebest: I wrote earlier that some clients replace (a), (b), (c) style enumerations with smileys

also, tell my mother how to make a word containing an "*" italics/bold with Markdown.

if I say the regex is .*bob.* and that ends up being bolded, you still get the message

Ge0rG, go and kill pidgin with fire already.

moparisthebest: no, because I can't copy paste that regex any more

Ge0rG, uh yes you can

it doesn't remove the *

Ge0rG, https://burtrum.org/up/30079903-aaa9-43c1-b08f-2642b7e7764d/open-screeny-23190.png

moparisthebest, emphasize "Trainer*Innen" please.

jonasw, *Trainer*Innen* works

that the bold'ing code missed it doesn't matter

it's still obvious in the reading

it’s super-awkward to read

only because your a programmer that likes ASTs :P

and no it does matter when a thing invented to do only exactly one thign literally doesn’t do that thing. ✏

I'm an experienced user of markdown and I regularly fail to quote a formula with two multiplication signs.

I disagree, it still conveys the same meaning whether it's highlighted or not

*this is bold* and so is **Trainer*Innen**, maybe? Just a thought (actual character doesn't matter obviously)

SamWhited, sure, but this is the point where you don’t want humans to write that.

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.

we can’t do that if we put things in <body/>.

it's not a problem that needs solved

Yah, fair, it's really not

moparisthebest, also, pandoc would highlight the first part and leave the second unhighlighted.

you don't need a spec or standard that solves every single edge case ever

that's also fine, gajim highlights nothing

moparisthebest, but it’s comparatively easy to do so!

I guess if you give me a huge editor with a ton of buttons maybe

I don't want that, I'll just type *trainer*innen* anyway

how does the sending client even know what I mean

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.

then you run into UI issues and such

the sending client can offer you neat in-line markdown preview support.

I have limited space on my phone screen as it is

I’m thinking like some tools do auto-completion. I can’t describe that in just one line, but the flow is amazing.

With LMC you just retry multiple times to fix the markup you never wanted, giving up in frustration after the fifth attempt

you really care to add any kidn of markup on the phone? I’d be too lazy to search for "*".

basically that, then I'd have to try to get it to look right

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/

where as if you display what I send exactly, and maybe bold/italic/underline part, it's fine

SamWhited, looks great

Maybe not with markdown, but something similar.

It's just a pleasant experience; I type **, my mother hits the "B" button. It all works out in the end.

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.

(in addition to a lightweight formatting toolbar)

(of course, turning off any kind of formatting would work too. and stuff pasted from clipboard would never get formatted automatically.)

or, you just type *foo*, recieving client may or may not bold it, everyone is happy, far less work, 100% interoperable

moparisthebest, if everybody sees different things that’s not interoperable.

that’s "it works"

it's different regardless

but not "it’s interoperable and works great"

I typed this in courier new and you are seeing arial, maybe

Yah, Jira does the backspace thing and it never works as expected. I'm unsure why though.

maybe we should start sending fonts and DPI values over xmpp too then?

SamWhited, hm. I’d put some effort to make it work, if you care to test at some point? :)

Sure

moparisthebest, of course not.

SamWhited, also, you can then try to exploit my webview-based message view :)

I am always game for that.

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.

but I don’t have XHTML-IM support yet, so ;-)

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

I’ll put the accessibility argument back in the ring.

those asterisks and underlines are annoying for a11y software.

and slashes etc.

If you didn't click it, also click the little eye icon in that web editor. It's the best part.

SamWhited, :)

much of this would be overkill for day-to-day IM use. but I definitely can see use-cases.

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.

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.

jonasw, a11y software presumably would ignore those strange characters, I don't really know

moparisthebest, I happen to know a few people who use a11y software.

what does it say when it gets to *foo* or "bolded foo"

SamWhited, I tend to agree that we might need some XHTML (but more than just the IM subset we had) for blogging cases.

but for IM, I see something like XHTML-IM + possibly A/V embedding minus the @style as useful.

moparisthebest, bolded "foo" leads to emphasis

the other thing depends on the implementation

but some will read out "asterisk foo asterisk"

what kind of emphasis?

tonal

I'm not sure what you mean

like it screams at you?

no, but like you would emphasize a word in a sentence. the whole point you use emphasis.

so I think my argument holds and is the same

someone who uses that software, depending on their client, would hear 'star foo star' or FOO with emphasis

I don’t think so?

and either way get the same meaning

no

they would get "asterisk foo asterisk" with spoken emphasis.

(if the client boldfaces the "*foo*")

still they know what that means

same as you or I know what it means when we read it

that’s bad accessibility.

really.

that’s the type of thing people dependent on a11y software switch softwares for.

it's identical to your plan of the sending client guessing all these things

no

the sender can revise and make sure it actually reflects their intentions.

they can’t do that on the receiving side.

but no their software would either say "asterisk foo asterisk" or "foo" with emphasis

either way they understand, no problems

why would they omit the asterisks if the client has them in the text view?

they understand, but it wastes time.

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.

now I'm curious how does a11y software read xhtml-im

it would have to be way worse

no

they read it like they read webpages

for which they are basically optimised

(you do realize that a11y software scrapes the widgets of applications, don’t you?)

BLUE FONT BLACK BACKROUND BOLD MARQUEE FOO

(of course, applications help with that via a11y APIs and such)

jonasw, not supporting font-family, color or color-background in @style is fine, but not supporting @style altogether is a bit bad imo.

And it’s trivial to parse and whitelist correctly.

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

Not only for microblogging, which wasn’t even my use-case back then.

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

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.

That’s why I would dislike to see @style disappear altogether, whether in XHTML-IM or in a next spec.

Not all of us are sad grown-ups. :)

<style color='rainbow'>hello</style>

And you seem to forget that using color in IRC is a crime against humanity and only annoying trolls and spammers use it

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.

Zash, I’m actually enjoying when IRC people send spoilers in spoiler-style, and biboumi renders them as wanted.

I'm sure someone will need a layout engine, but that thing needs to not be XHTML-IM.

We need to figure out how to create something that won't end up with such an abysmal security record.

Extending the broken thing we have won't make that better.

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.

Good for you, it would be the first I've ever seen.

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.

That argument that it’s broken by definition is quite dubious.

SamWhited, we need better security guidelines, two days ago I reviewed the current ones and they are abysmal.

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.

I agree the current ones are terrible and could be improved, but it won't fix anything.

You just discarded any web client here.

(although we should do it either way, hopefully it will help at least a little bit)

The defaults of these APIs is to be insecure.

Yes, but unfortunately I can't change that spec.

XHTML-IM isn’t any more or less insecure than RFC6121 here.

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.

(Yes, I’ve seen implementations shove <{jabber:client}body/> into the DOM.)

SamWhited, sure.

It’s just a bogus argument because as a web dev you have to code extremely defensively all the time.

Sure, you should, but I don't see what that has to do with anything

But sure, for the sake of argument let's ignore the people that will do the obviously wrong and broken thing

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

I'm not convinced we can make the web not be broken by default

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.

We can make something where any trivial mistake isn't a critical security issue.

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.

I am not saying anything of the sort

Of course you can always get something wrong, you can always introduce security issues, etc.

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

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.

Link Mauve: I agree, that is the correct way to go.

SamWhited, we can’t make any spec if the goal is to make web devs develop non-defensively.

That's also not what I said

Zash, same. :(

I said we shouldn't be *relying* on the fact that web devs will code defensively and make no mistakes.

Everyone has to be defensive, including us. We can't just assume the burden lies entirely on the application developer.

Right, by providing them tested implementations, by providing them clear security guidelines, by encouraging them to do the correct thing.

Not by rewriting what works into something which works less well already.

SamWhited, sure.

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.

We need something where the default isn't broken and where every mistake isn't an issue.

I disagree on that.

You can’t have a non-broken default on the web.

It’s just impossible.

Because it’s broken by design.

Sure you can, a number of techniques have been discussed.

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.

Please read the mailing list thread, we're literally just reiterating the exact same things that have been said on it.

I have read it entirely already.

And no matter what you replace it with, div.innerHTML = parse_markdown(message.body); will exist.

Why do you think we would encourage replacing it with something with the exact same issues?

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.

Deprecating XHTML-IM means people will find other ways to do formatting, the discussion we had earlier has terrifying examples of that.

And replacing XHTML-IM (and subsequently deprecating it) has exactly the same issues as XHTML-IM has currently.

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

No, again, read the list, there have been multiple suggestions that do not have the exact same kind of issues.

I have, and they all have them, even the JSON-based protocol break solution has them, if you don’t sanitise your input properly.

anyways, I've got to run

And I, to sleep.

See you! \o_