XSF Discussion - 2017-11-06

Holger: done. Check your mail.

can I have an account there too?

zinid - xramtsov@gmail.com

Done.

thx

SamWhited, you might want to update https://wiki.xmpp.org/web/Sam_Whited_for_Council_2017#Better_recommendations

jonasw: Actually, the deadline for applications has passed, so we shouldn't be editing our applications really.

Kev, I know. I just wanted to point it out for Sam to judge, given that the content is obviously deprecated and the thing which is deprecated has changed before the deadline

Happy to see that we at least have a full complement of candidates. I was worried there for a bit.

Kev, also, MattJs application for board is still null

Don't think that's true.

Kev, then at least it’s not properly linked

Have you tried clicking it? :)

there's a page for Matt, but the link shows red for me. Some weird caching issue in mediawiki that I though was fixed.

no. stupid caches.

the three issues in computer science. Cache invalidation and Off-by-one errors.

I like how 50% of the applications were made on the day of the deadline.

I don’t like that.

you're right, it's not ideal, but it's funny to see how procrastination is at work each time. At least, I'm hoping that it's just that.

I too do hope that

Usually is for me when I'm late at putting up my reapplication ;)

is there a summary on how the voting for Board & Council works for those who find the Bylaws hard to read?

is it that you vote for each individual yes/no and each individual has to be elected by majority to be part of that group?

if so, what happens if n>m (where m being the size of the group) individuals get elected?

I'm just hoping that procrastination combined with wiki account loss didn't prevent people from applying.

jonasw: I don't know, not do I think your explanation was clearer than the bylaws 😉

I’m sorry :P

Guus: I was considering applying but I gave up as I've already too much work and I can't take any more engement this year.

commitment*

jonasw: Top five, basically.

top five with respect to what?

do we get one yes/no vote per candidate?

ISTR we pick (up to) our chosen five, those count as yes, others count as no.

istr istr istr

I...

it stands to reason?

goffi: totally understandable. I'm just hoping that there we not people that did want to apply, but ended up missing the deadline because the forgot about / were not aware of the loss of wiki accounts

(we had a couple of requests tonight to recreate accounts, which made me wonder)

I seem to recall

Guus, I’m confident that those people would step up if that was the only reason

in which case I’m sure that we could extend the period retrospectively since this was an issue outside of their control

I kind of disagree with the 'outside of their control' classification, but would be in favor of accepting late candidacies.

If anyone had said they needed an account, and didn't get one, yesterday that'd be one thing, but if anyone comes in today and says they want to apply, they obviously missed it.

There's the "ah, I couldn't sign up and was confident that requesting a new account wouldn't get me a new account before the deadline" argument. If we would be extending the deadline (which I don't think we are), there's not much reason to accept one type, but not another.

I suggest we stop debating what to do in a situation we don't have :)

:)

it’s monday morning, don’t judge people for a desire to distract themselves with irrelevant scenarios

Kev +1

by the way, is there people that are interested to come to T-DOSE this month ? https://wiki.xmpp.org/web/T-DOSE_2017

I'll be at T-Dose! :)

let me put out a tweet for that event

edhelas: we should prepare for some demos and the like. Thoughts?

edhelas: would you mind drafting a blogpost that announces our presence there?

I don't have much time for that atm sorry

Guus: by the may, I need to recreate account too

no that you're talking about it :p

now*

goffi: desired nickname and email address please

It looks like we finally have a situation where wiki account creation is almost instant.

Guus: answered in P.V.

Ge0rG API over XMPP MUC

XML-RPC!

ad-hoc commands

that works great

I love this XEP

if only it was more user friendly

why would it not be ? It's a client thing to make is user friendly

http://www.t-dose.org/node/1063

Guus: Got the account email, thank you.

Holger: yw

isn't it easier to add <subscribe/> to MUC XEP instead of writing this MIX stuff?

It's certainly easier to write that, yes.

Zash: tell us about minimix

Guus: so what's the problem? we can create those pusbus nodes inside a muc room

*pubsub :)

ha I like pusbus better we should rename it

no objection

I vote for pup-soup. 🐶🍲

also, assuming a user's server should know about MIX is a bad idea

another issue: > To achieve this, the client will query the user's own MAM archive using Message Archive Management (XEP-0313) [3], with the query filtered by the channel JID. > The only exception to this is when a user wishes to access message history in the channel prior to when the user joined the channel. To achieve this, the client will use MAM to retrieve message history directly from the MAM Archive of the MUX channel.

why a client cannot request mam archive from MIX channel right away?

zinid: you should read up the previous discussions on standards@

which ones?

the ones on MIX

there are tons of them

Yes.

no thanks

I just did some search and didn't find any relevant info inside those discussions

memberbot is up and council for the board & council election

Alex, thanks :)

even though I assume it’s up and running, and not up and council :-)

Alex, you included ralphms application despite it being late?

(I’m not saying that we should not, but I think that some people have strong opinions on that)

yes I did

"""Your problem is so terrible, I worry that, if I help you, I risk drawing the attention of whatever god of technology inflicted it on you."""

:D

please don't walk in the sea.

into*

I LOL'd so hard reading that

Arc: That sounds like how helping people with old code makes you the maintainer.

Yeah, I get funny looks whenever reading his book

The What-If book?

yeah

he might have more, unsure :)

Is that from What-If?

no

xkcd

it’s todays xkcd, Zash

Bunneh: xkcd

Thermostat https://xkcd.com/1912/

Guus, I learnt in that book that I both want and totally not want a wall with the periodic table of elements :-)

I learnt from that book that I snort when snickering

:D

im digging through my old code with mod_xmpp now, doing a major overhaul. its actually not terrible, just a bit ... spaghettified

i was actually closing in on a "good" solution but was one step away. instead of chopping up stanzas by the outside, i needed to chop them from the inside.

what’s mod_xmpp?

"not terrible"

(just a bit spaghettified)

jonasw: it started as an Apache module to do XMPP over Websockets proxying to an xmpp server over C2S

ah

Guus: i know I'm not unique in, when you work on code you havent touched by a year, you start hating your younger self

Arc: I totally bypass that by simply forgetting that I touched that code. As long as I don't use git blame, I can hate the random anonymous dev that did that terrible thing.

heh

Or, as one of my code-workers used to say: "I must've been drunk."

Guus, +1 for "I must’ve been drunk."

or high.

it’s extra funny since I don’t drink alcohol or so at all.

... that you remember ...

right.

I also find that this varies greatly by language.

so, I'm looking at chopping up the XML stream by the inner part of the stanza, and parsing/serializing the outer part of the stanza. does that seem sane?

I’m not sure what "chopping" means and why you need to do it

(also, jdev@ maybe)

obviously open to edge cases, but I'm still using expat with this, and I'll move to libexi in a later version meaning it'll do a full parse->serialize during the process

jonasw: outer part, eg, <message from="" to="" id="">, vs inside part eg <body xmlns=""> etc

I guessed that much -- what kind of chopping?

oh man, i havent been in jdev in forever

(I may be missing context on how websockets work)

jonasw: its semi related to websockets.. chopping actually in regard to APR bucket brigades. so Apache operates streams as a linked list of buffers. when the expat parser hits certain markers, I record the point, and then can recreate/remove part of the stream, then grab the buffer until a certain termination point, passing that along verbatim

okay, what

one of the bugs in mod_xmpp has always been that, contrary to spec, it hasn't included xmlns="jabber:client" with every stanza

huh, is that a MUST or SHOULD?

didn't you get all that from 'spaghettified code', jonasw? ;)

namespace can be either on the stream or on each stanza, iirc

my personal style of test-driven development (which is much less strict than what people probably usually advocate, I don’t know, I’m self-taught) has stopped me from writing spaghettified code

its a MUST because XMPP over WebSockets isn't within a root <stream:stream> element anymore. each stanza is a whole and complete XML document

I think so too, Guus

Arc, okay

I was scared there for a second

https://xmpp.org/rfcs/rfc6120.html#streams-ns-content

most javascript code implementing xmpp over websockets doesn't test for the xmlns="jabber:client"

I'm not so sure that doing that wrapping thing was the best idea

because I’m pretty sure that aioxmpp doesn’t include xmlns="..." on each stanza

ah, websockets

Arc, most javascript code doesn’t give a f..thing about namespaces.

and if you try to do, you run into all kinds of funny browser bugs.

it's annoying to have to move stanzas from a c2s stream to a s2s stream, for the difference in namespace

Guus, I agree that using different namespaces there was a weird choice

All that because nobody wanted to write a SAX parser for browsers

asm.js + libxml2?

or libexpat

jonasw: but now it's set in stone forever and ever

Zash, until XMPP 2.0 comes around or so...

maybe a "just plain XMPP over websockets, no fancy framing" spec?

wouldn’t that break due to lack of SAX parsers?

i dont think the namespace actually breaks anything in javascript

jonasw: I mean as a separate thing

more separate things?

but yea in WebSockets the second example in guus's URL, "prefix-free canonicalization", is what websockets stanzas SHOULD look like.

The current XMPP-over-WS RFC is basically "XMPP over WS for the Web"

Zash, is there a use-case for WebSockets not for the Web? ✏

damnit

The dark future where only port 443 can be used?

Zash, don’t support that dark future

(and don’t walk into the sea)

And where you can't tunnel whatever over TLS on 443?

I don't

It's of course inevitable tho :(

Zash, stop saying that

you make me sad

I don’t want to be sad.

in that particular example, xmpp connect might actually be faster than starttls

Arc, even faster than XEP-0386?

jonasw: no, because you have the HTTP upgrade handshake

wait that number is wrong

i know what you mean tho

and i love it.

XEP-0368 (SRV records for XMPP over TLS)

I mean its a bit rough around the edges, i wish it wasnt needed, that xmpp were to default over TLS

zash is right tho, there's already networks that block all communication that's not on an "approved" protocol on its "accepted" port

HTTPS must be accepted.

Arc, I’m not sure pushing that fight further up in the ISO/OSI layers will help

we've had some form of XMPP over HTTP proxy to deal with those kinds of networks

It's all just moving negotiation around the layers

Arc, at some point, either breaking of TLS by those firewalls will becmoe standard or other means of guessing the type of traffic will be used.

at some point those firewalls will also include ALPN sniffing

Arc: Implying that they don't already?

point

i still have a WRT54GL router setup exclusively to proxy all IP traffic over HTTPS because most school districts have only 80 and 443 open, and block *MOST* websites on both. Luckily I own an IP address not currently included in any blocking blacklist

the DC Public Library system was setup similarly. good luck getting a video conference to work

it was otherwise impossible to do after school programming

> jonasw‎: Zash, is there a use-case for WebSockets not for the Web?

unfortunately yes: https://github.com/moparisthebest/WebSocketSocket

for a brief period my work mitm'd all TLS and I had to tunnel TLS over websocket over mitm'd TLS

luckily I did not write a XEP :P

Guus: also man, given the attendance record for the last board, i dont think you have much to worry about. really.

we clearly need new, energized blood

(even if its me that's out the door for next year)

I'm not worried either way, just wanted to make a House of Cards reference.

heh

because i think that's hillarious.

there.

well, no HoC reference is complete without accusations of gay rape

might be nice to link to https://wiki.xmpp.org/web/Board_and_Council_Elections_2017 in topic

I pledge that I only sexually harass men when asked to by women who feel harassed by those same men. :-P

PyCon before the CoC was a very dark time.

hey Kev how solid is MIX at this point?

pretty solid if you mean too dense to read :P

is there a reference implementation yet?

moparisthebest: did you ever see or read my presentation on xmpp microservices?

Arc: I read your EXI xep

no, got a link to read?

zinid: that's impossible, i havent written it yet

moparisthebest: just read his EXI xep to get the idea ;)

the only exi xep that exists now is garbage

Arc: there's a MIX implementation for Openfire being worked on by Surevine - not sure in what state of completeness it is.

I'm not positive EXI has a purpose outside tiny embedded devices really

the XEP as it stands does not sync the grammar to be used, it relies on the server taking several schemas and compiling a grammar itself, which depending on implementation may or may not match

like mobile phones handle XML just fine

moparisthebest: yes, it absolutely does. the problem is imlementation

Or lack thereof?

why would a phone app want to implement something other than XML though is the question?

of course it does. mobile devices can handle XML, but the overhead is immense. to say "hi" takes 200+ bytes

Arc: ah, you're not the author, ok

certainly no memory or speed reasons anymore

in a world where node.js is a thing, what's 200+ bytes?

a hello world webpage is ~4mb

Bunneh: do #'<message to="arc@example.com" type="chat"><body>hi</body></message>'

Zash: 67

Arc: but EXI is a terrible way to fix this issue, at least current XEP is pure shit

abstracting from XML is a way to go

zinid: yes, it absolutely is. which is why i dont want to fix it. i want to write a new one

zinid: Separation of the data and its encoding?

Zash: yeah...

what I'm missing is a manner for the client to transmit the grammar to the server when the server doesn't already have it. there isnt a standard encoding for this, and it must be implementation agnostic

and sounds like a nightmare security-wise, probably

i dont think so. why would it?

why would you need to transfer schemas? do you know any asn.1-base implementation transfering asn.1 definitions?

I wonder if EXI grammars can be used to create exponential costs (they can contain regexes, right?)

the current XEP does something, security wise, awful in having the server fetch grammar files from arbitrary HTTP URLs. that's begging to be used as a DDoS amplication attack

I vaguely recall discussing this before, I think you said the server would cache these or whatever

or does the client transfer all it's going to use every session?

because then you don't save bytes

Arc, is it so important to do that? I've heard that EXI works reasonably efficient even when not used in schema-informed mode

moparisthebest, I think the grammars would be keyed by a cryptographic hash sum

What if each party says which namespaces they have schemas of, and then you fall back to some inefficient generic encoding for everything not in the union of known schemasq

s/q$/?/g

Flow: reasonably is relative. you have to transmit all your string tables

Zash: aka non-strict encoding.

so can evil client fill up that cache and/or boot out other in-use ones?

moparisthebest: SHA256 should reasonably cover this, unless you think SHA256 is weak. and the server could have a finite cache.

my point is EXI seems possibly useful in a iot network of trusted super low resource clients or whatever

and useless for desktop or modern phones

(which are now, indistinguishable resource-wise, right?)

you cannot trust iot devices. thats where terrible iot security comes from.

so can't I just evict your useful grammar files by sending you a load of useless ones?

moparisthebest, mobile devices may have similar computing power than desktops, but they have other constraints too

even if you do everything correctly and sha256 is secure

LRU cache?

yea

moparisthebest, use a very limited per-account cache, plus a global cache for shasums which are used by multiple accounts.

in the worst case the global cache is filled with garbage, but the account-local caches for well-behaving accounts will still work as they should.

jonasw, so then I just connect 2 evil clients and still evict from global?

moparisthebest: Think of EXI as better compression that is safe from https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/

Zash, are you 100% sure that EXI isn't vulnerable to similar form of attacks?

ah yea I think we talked about that too and weren't entirely sure it was safe in all modes

regex btw is an argument against transmitting schemas, its primarily used when defining constrained character sets, and the regex in question isn't a full regex implementation but rather a list of character ranges

Flow: I'm not 100% sure of anything

s/safe/safer/ probably

in fact I think Arc said it was vulnerable in some modes

it's been awhile

moparisthebest: there's vulnerabilities in all XML libraries.

Zash, ok, let me rephrase: Do you expect that EXI is not vulnerable to similar things like CRIME/BREACH?

Arc, sorry I meant vulnerable agaist crime-like compression attacks

Flow: I expect that kind of attack to not be effective against something that roughtly boils down to byte-packing of Enum-like fields

well EXI includes the option for including DEFLATE

there are 4 modes; bitpacked, byte aligned, pre-compression, and DEFLATE

the client chooses.

honestly ive found bitpacked to work the best in almost every case

in bitpacked mode there's no huffman table or similar to exploit. it doesn't compress text really at all, only XML structure.

if there's a potential attack on DEFLATE i'd be personally satisfied in including it in a Security section of the XEP with an advisement against using it.

If you make sure that any fields that an attacker can put stuff into are treated as text then it should be more resistant

*nod*

I believe I remember seeing a case of ascii-only 6-bit encoding, and UTF32, intermixed.

but that's about the only text compression you're going to find

5 bits should be enough for everyone! :)

until its not. :-P

insert unicode emoticon.

I wonder size-wise how it compares to that xml->json thing, was that a xep?

Arc: It the wrong usage of DEFLATE that opens the side-channel. If the attacked endpoint performs a full flush, i.e. drops the dictionary, on every "channel" change, then it should be safe

Flow: interesting. well, that's something we could address. XML fragments are included, i honestly dont remember how compression was supported.

Flow: I think that should have had a protocol break

i remember i talked to sam a lot about using framing with it, and each stanza a full and complete xml document

Zash, why?

Flow: How does one end know that the other end is doing it Right?

yep, no way to tell, no way for server configs to forbid insecure clients

the core of the argument for mobile comes down to this tho, the reason Google dropped XMPP support, according to one of the guys on the Hangouts team, was the massive bandwidth and processing overhead of XML vs binary.

so XML was an engineering problem google couldn't tackle?

Arc: Is that why they pushed for HTTP/2 to be binary?

because marketing sounds far more likely

moparisthebest: XML has a very high processing overhead, and bandwidth overhead, and those are things that can't be just "tackled"

remember when i accidentally crashed gtalk?

Text based protocols do have other valuable properties tho

google engineers didn't know about EXI or some other encoding?

Zash, the other end being the other end of the stream or the xmpp communication?

Flow: Yes

:D

I just find it hard to believe the reason wasn't "we want to lock people into our walled garden"

I'm not sure if in the c2s case, the client needs to know that the server also does full flushes on channel changes

Isn't it possibly sufficent if the client does the right thing?

that was due to an optimization in their UTF8 to protobufs handling. a shortcut was taken, the message i sent jumped their double null termination and propigated.

Flow: How do I, the server, know that you do the right thing if the protocol is identical?

Zash, you don't, but do you care as server if, for the example, the client authenticated your TLS cert?

𐑓𐑳𐑒 𐑿

that exact message was all it took.

Flow: just <method>zlib-but-better</method> is what I mean

-demoji Arc> 𐑓𐑳𐑒 𐑿

Zash: Arc> 𐑓𐑳𐑒 𐑿

Arc: hexdump?

not emoji zash. its shavian https://en.wikipedia.org/wiki/Shavian_alphabet

Zash, sure why not, but you could also do the better part as client with <method>zlib</method>

The client has the incentive to do the right thing, the server doesn't really care, that is what I mean :)

Flow: You think the server should you just let you shoot yourself in the foot? :)

it reads "F-U-K YEW" which is what I wrote in jdev several years ago, when gtalk was brand new, to a google dev who argued that there's "no difference between characters and bytes, thats why we use UTF8"

what

Zash, the server will happily route my root password in <body/> to your JID, won't it?

whatever optimizations they used, the space there caused their parser to jump the terminating null plus the two "safety nulls" they had in the protobuff reader and cause every gtalk server processing it to crash

Flow: You think the server should just let old non-fixed versions shoot themselves in the foot?

google devs found it as the last message in the queue in every affected server, and they "decoded" the phonetic english

"safety nulls"

amazing

Zash, valid point. So you prosody implement zlib-but-better?

this was a long, long time ago, but yes. their "optimized" xml/utf8 decoder had two "safety nulls" to ensure that this wouldn't happen. they didnt expect 4-byte unicode

s/you/would?

nobody does expect 4byte unicode (*glances at mysql*)

one of the guys from the gtalk team shared that bit with me a long time after it happened.

as mod_compression_safe ;)

Flow: Maybe, if it get's properly XEP'd, but no promises

anyway the biggest issue for EXI right now is *how* to communicate the grammar.

Wasn't there even a TLS compression extension for CRIME or something?

Arc, bytestreams?

Or what exactly is the issue? That there is no mechanism defined?

Does it really need to be communicated at all?

My question exactly

Flow: no, no XML schema or otherwise that Ive ever seen.

Flow: the gains for it are huge, especially for initial connection.

I'm sorry but I don't follow. It is not required to exchange grammar to the other endpoint for EXI do work, but it would improve things, right?

Then why not: 1. authenticate 2. upload grammer via base64 encoded stanzs. 3. activate exi 4. bind

Or is the grammar byte format not well defined?

Flow: because you don't want to require the client support text-mode XML. especially with IoT

Arc, ahh ok, Smack's EXI protype would always work on XML, so that is what I thought would everyone do

Arc, 1. activate exi, 2. upload grammar via exi-encoded stanzas, 3. use grammar, […]?

What is the other thing besides text mode XML? binary XML?

Flow: https://www.w3.org/TR/exi/#informedGrammars

regarding the Styling XEP proposal, XMPP is a "protocol", this means it has to stay in the backend on my app, telling it what is received and what to send, XMPP is NOT a protocol that enforce how my app should look like, with Markdow, if I want to display my messages without formating I'd have to remove manually all those ugly ~ and *

Flow: EXI uses a lot less code to implement. so yes, text XML vs EXI

Maybe I'm a bit inflexible, but I can't think how a XMPP client/library/server would work with pure non-XML EXI exclusively

Flow, _xmppexi-client._tcp SRV :-) ✏

It sure is possible

jonasw!

Zash!

jonasw: I was just typing that

Flow: client connects and sends a EXI header, specifying the schemaId as sha256, if server doesn't support it it'll respond with a default EXI grammar specifying this, client sends a new header to transmit the grammar

it adds a handshake if its unsupported

the grammar can be informed by a schema but includes weights. I might be wrong, and i'd love to be wrong, but I am not aware of an implementation-independent way to specify weighted options in an EXI schema

the grammar is a tree

the tree is scoped by where you are, and the options available at each point. more common options use fewer bits, or even only one bit. eg, end element is commonly transmitted with the first bit

in non-strict encoding there are options at every step, even for elements which have no attributes, child elements, or content

tho that can be transmitted with a single bit, end-element, or "other"

ive skimmed a few other EXI libraries for other languages and they all represent this slightly differently.

just, if _xmppexi-client._tcp becomes a thing make it '368 style direct-tls please :)

moparisthebest: you have my whole-hearted agreement there

I do not like the idea, tho, of having to invent a XML schema to represent the grammar. because that has to be documented, and it'd be complex.

edhelas: please post your remark on the @standard. The worst with the current proposal, is that you can't even know if you have to remove those ugly ~ and *

You can choose

It basically describes what most clients do anyway

Which "most clients"?

Thunderbird, Gmail?, Hexchat, every IRC client I've *ever* used, people writing text from the beginning of writing text when nothing parsed that except people, gajim

I'm missing a ton surely

Point is, parsed or not, it's well understood by anyone reading it

If everyone understands it already, then do we need to do anything?

Nope that's the beauty of it

You don't have to do anything

would be fun to post "ls `date +%Y-%m-%d`-*.xml" in a shell@ MUC room with some of client using this XEP some others not using it.

goffi: I recently learned about `date -uI`

Zash: easier to remember :)

oui

goffi: so highlight but keep characters?

moparisthebest: that's probably for the best

I think keeping the characters vs. hiding them is a client decision FWIW, but I really like keeping them (eg. use https://simplemde.com/ for a while, it's very pleasant)

let's add one more different way of rendering

I just changed my implementation to keep the characters bit display them with 50% opacity

*but

Gajim keeps them

Have to check others...

Yes I'm starting to think that keeping them is for the better. And maybe the xep should specify that (the characters have to be kept)

I would be happy to change that to say that you SHOULD keep them, I only didn't do that because I assumed people would complain if I did.

I guess you can never fully avoid false positives

daniel: yes, by properly marking when you use a rich syntax and when you are not

If we decide to keep them we should specify if the style should include the keyword

I opt for not

Because it looks better

daniel: I'm not sure what you mean, do you just want to make eg. the * bold but not the word?

goffi: then rewrite all e2e xeps, carbons, and come up with some nightmare to check if the content sent 2 different ways matches in content meaning

Or, keep. It. Simple.

SamWhited, if *bold* will render to <b>*bold*</b> or *<b>bold</b>*

and i think the later looks better

:')

<b>*bold</b>*

daniel: Ah, right. Tentatively I *think* I agree with you.

Good compromise

we all agree that next to the type="markdown" content we will have an unformated classic <body> tag ?

I think gajim bolds the asterisks too, not on it now though

especially if you then go and display the * with 60% opacity

moparisthebest, yes it does

this is just coming from my personal preference on what i think looks better. not what other clients do

I think it actually doesn't matter but the xep should recommend

edhelas: no, I think that's exactly what many people here are trying to avoid

sic…

can I also invent my own markup for Post content published in Pubsub ? like in Microblog then ?

something that is like Markdown but with my own personnal syntax

moparisthebest: no all e2e XEP, OTR and OMEMO, and we already complained about that before. OX is done the right way.

then people can embed videos and centered texts, but without using XML

moparisthebest: and you'll have to rewrite RFCs if you don't want different contents.

I'm half serious here, or you go full Markdown or you do nothing, because I don't think developpers with love to write their own parsers again

but at least if the XEP mention a MUST (and not a SHOULD) keep formatting characteres, I would be more OK, as I could safely just ignore it.

goffi: so I'll just use the clients that implement ox then, oh wait that's none...

i can get on board with a MUST. i like strict XEPs anyway

daniel: with a MUST I don't see any issue right now (beside your pasted code being ugly on some client, but that's their choice)

just updated Conversations master in case someone wants to see how this looks like

actually forcing formatting characteres would not work with escaping. So this would mean removing escaping

I think daniel already said that and I agree

Removing escaping that is

Yah, removing escaping seems fine to me

I'll add that to my TODO list assuming no serious counterpoints are brought up in the list discussion

I've mentionned this in a new message, I'm done with standard@ flooding for today :)

or we are already tomorrow, I can flood again

oh*

(this joke only work in CET timezone)

SamWhited: your XEP looks good to me

Arc: thanks! Any oddities you find, things that aren't clear, etc. please let me know!