Re: [Standards] One true final way to mark up messages

[Evgeny]

On Wed, Mar 27, 2019 at 11:17 PM, carlo von lynX  
wrote:

XMPP will be nearly completely dead in coming years
as it has always refused to change the fundament of its
inflexibility


Hey, dude, how is your psyced going? Oh, it's dead. Okay.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown needed by a modern messenger [WAS One true final way to mark up messages]

[Ненахов Андрей]

чт, 28 мар. 2019 г. в 01:00, Sam Whited :

>
>
> On Wed, Mar 27, 2019, at 19:33, Ненахов Андрей wrote:
> > How do I turn off markdown processing on your side? I don't even know
> > you do have some thing that misformats my message despite having no
> > intent to be misformatted that way. This is especially a problem when
> > someone is trying to pass parts of computer code or config.
>
> What I'm saying is that *I* want to decide what messages I receive look
> like, why would I want you to be able to arbitrarily turn on or off *my*
> formatting?

Rich text format is a feature that should be explicitly announced, like in
XEP-0071, and with a fallback provided to non-compliant clietns. If you do
some kind of implicit rule that affects output on one end of
communications, it ends badly. I've actually had some experience with this
style of work early in 00s. There were ICQ clients that did some processing
of text, replacing *this* with bold and :) with ugly animated smileys. It
caused an immense amount of grief and pain. Not going back to it again. I'm
kinda OK if someone wants to have markdown-like synthax, but in  tag and with providing a legacy , like 0071 did.

Of course, it doesn't address other goals that we aim to achieve.



> If you send me a message, I should be the one to decide if I
> use your plain text fallback (eg. *bold*) or the actual markdown (bolded
> text). You shouldn't get to decide what I see and don't see. If you
> don't want me to see styling, don't send me something with styling
> directives.
>
>
> > >  Put another way, just because I want to support bold and italics
> > >  doesn't mean I want to support attaching images.
> > Me neither. I just want them to be neatly organized easy to digest and
> > undestand, without gaps and overlaps.
>
> I agree with that, but reinventing the world again doesn't seem like a
> good way to get there. Just tweak and polish the existing things (unless
> of course one of them really doesn't meet users needs, then we may have to
> rewrite individual components


Well, I imagined the process as fixing 0372 first, then updating 385 and
394 to match it. Removing obsolete XEP references, unifying some rules of
formatting the legacy body, etc.


-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[W. Martin Borgert]

Quoting Sam Whited :

IM isn't the web,


I agree. IM messages are - in general - short. Named URLs allow
shorter messages, that are better readable esp. by non-technical
people. In the context of 0393, I suggest something like:

[http://shakespeare.mit.edu/macbeth/ The Tragedy of Macbeth]

and

[xmpp:x...@chat.yax.im?join Off-topic MUC]

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[carlo von lynX]

SCNR to respond to this absurd thread...

On Wed, Mar 27, 2019 at 05:52:47PM +0500, Ненахов Андрей wrote:
> Obviously, we want to be able to have basic markup:
> *bold*
> *italic*
> *underline*
> strikethrough
> hyperlinks 

Agree with others that hyperlinks are no good.. mostly
suitable for phishing. Regarding the rest, the best
markup syntax for rich text is XML, IMHO. Unfortunately
XMPP is itself a dialect of XML, therefore embedding
XML in XML is a terrible mess and so you are forced to
discuss uglier solutions like the ones you listed.

But the mail gets even better than I expected:

> Modern messengers are capable to send various media, often presenting it as
> such.

XMPP was born during the short period of XML hype when
the Internet was 100% convinced that XML is the syntax
to solve all problems. Unfortunately embedding media
into XMPP is horrible. HTTP is much better for that,
that's why all modern messengers are using HTTP - with
funny side effects like messages arriving in wrong order.
But in exchange you get embedded audio, video, photos
and all that - which in this day and age is an absolute
must. XMPP will be nearly completely dead in coming years
as it has always refused to change the fundament of its
inflexibility, the bad choice of building on top of XML -
while new generations will not even consider a messenger
that cannot deliver an audio clip. Now you say, but we
can upload the audio by HTTP without actually embedding
it. Yes, but that increases latency as the client must
fetch the audio only after it got info about its existence.

> I could include more examples, but I think a picture is already clear.
> Thoughts, anyone?

Within the limitations of XMPP, your ideas are among
the least worst.

-- 
  E-mail is public! Talk to me in private using encryption:
   //  http://loupsycedyglgamf.onion/LynX/
  //irc://loupsycedyglgamf.onion:67/lynX
 //https://psyced.org/LynX/
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Sam Whited]

On Wed, Mar 27, 2019, at 20:01, Ненахов Андрей wrote:
> Ever heard of that insanely popular thing, Telegram Channels
> ? If you ever were subscribed to
> any more or less popular channel, you would not ask these question.
> There are no reasons why we can't replicate that functionality in
> XMPP. Of course, the line has to be drawn somewhere, but it's not on
> named links.

I have, but I've also heard of lots of other messengers like WhatsApp
and Slack that don't allow this. Like I said, I'm not entirely against
it, but I don't see a compelling reason to add that level of complexity.
Let's start with the bare minimum and add features as we discover actual
problems that need to be solved. It's easier to add a feature later than
it is to take a feature away after users have already gotten used to it.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Ненахов Андрей]

> That's not an instant message. Are you expecting long form content to be
> distributed in XMPP that needs design? Does that mean we add fonts?
> Ligatures? An entire layout and content system as well?
>
> IM isn't the web, I'm asking about what benefit you think links provide
> in the context of IM, not the web.
>

Ever heard of that insanely popular thing, Telegram Channels
?  If you ever were subscribed to any
more or less popular channel, you would not ask these question. There are
no reasons why we can't replicate that functionality in XMPP.
Of course, the line has to be drawn somewhere, but it's not on named links.

-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown needed by a modern messenger [WAS One true final way to mark up messages]

[Sam Whited]

On Wed, Mar 27, 2019, at 19:33, Ненахов Андрей wrote:
> How do I turn off markdown processing on your side? I don't even know
> you do have some thing that misformats my message despite having no
> intent to be misformatted that way. This is especially a problem when
> someone is trying to pass parts of computer code or config.

What I'm saying is that *I* want to decide what messages I receive look
like, why would I want you to be able to arbitrarily turn on or off *my*
formatting? If you send me a message, I should be the one to decide if I
use your plain text fallback (eg. *bold*) or the actual markdown (bolded
text). You shouldn't get to decide what I see and don't see. If you
don't want me to see styling, don't send me something with styling
directives.


> >  Put another way, just because I want to support bold and italics
> >  doesn't mean I want to support attaching images.
> Me neither. I just want them to be neatly organized easy to digest and
> undestand, without gaps and overlaps.

I agree with that, but reinventing the world again doesn't seem like a
good way to get there. Just tweak and polish the existing things (unless
of course one of them really doesn't meet users needs, then we may have to
rewrite individual components, but I suspect we have all the building blocks we 
need already and this won't be necessary).

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Sam Whited]

On Wed, Mar 27, 2019, at 19:41, Ненахов Андрей wrote:
> Not all messages are born to be sent in a quick and dirty way. They
> are better because they don't look like they were sent by a lazy geek.
> Some usecases require a craftily structured beautiful message. Of
> course, you'll say that 'this is not the answer'.
>
> All right. Let's dig deeper: image.png
>
> Why didn't you write,
>
> n. *Informal* a simple theme for https://octopress.org and
>http://jekyllrb.com/ by https://blog.samwhited.com/ A live preview
>can be found https://web.archive.org/web/20170719001930/
>https://blog.samwhited.com/
>
> ?
>
> From what you're saying, this is no worse, no?

That's not an instant message. Are you expecting long form content to be
distributed in XMPP that needs design? Does that mean we add fonts?
Ligatures? An entire layout and content system as well?

IM isn't the web, I'm asking about what benefit you think links provide
in the context of IM, not the web.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[W. Martin Borgert]

Quoting Sam Whited :

What is the use case for hyper links and who does it benefit? I
keep hearing people say they want them, but I don't really
understand why they're necessary over just auto linking things that
look like URLs. Thanks.


URLs are sometimes readable to me, sometimes not.
For most non-geek people URLs are never readable.
Therefore, HTML has an anchor element with content and
not just auto linking. Mainly an aesthetical question.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Ненахов Андрей]

> This isn't an answer; how do they benefit users? How is this better than:
>
> "Hey, here's a link to the XEP we were talking about:
> https://xmpp.org/extensions/xep-0001.html";
>

Not all messages are born to be sent in a quick and dirty way. They are
better because they don't look like they were sent by a lazy geek. Some
usecases require a craftily structured beautiful message. Of course, you'll
say that 'this is not the answer'.

All right. Let's dig deeper:
[image: image.png]

Why didn't you write,

n. *Informal* a simple theme for https://octopress.org and
http://jekyllrb.com/ by https://blog.samwhited.com/
A live preview can be found
https://web.archive.org/web/20170719001930/https://blog.samwhited.com/

?

>From what you're saying, this is no worse, no?

-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown needed by a modern messenger [WAS One true final way to mark up messages]

[Ненахов Андрей]

Why not? As far as I can tell that's what most things do: just stick a
> center dot on it. In HTML I'm pretty sure most renderers put a center
> dot in the before:content area (I don't actually know what this is
> called). A client could do this just as easily.
>

Well. Fire up a LibreOffice, and do a simple default unordered list. Then
try to replicate the exact nice appearance of it using dots and whitespaces.
Also, it would ruin text semantics if someone will try to copy-paste it.



>
> > Because your plain text version does not work everywhere. I somehow
> > forgot to mention the abolute worst thing about 0393 as it it's
> > written:* now do you suggest disabling processing these * and _ on
> > remote end*??
>
> Why would you want or need to do that? They make a good fallback. If
> your client doesn't support *bold* it's still obvious that I wanted to
> put emphasis on that word when you see plaintext wrapped in *'s.
>

Why would you want or need to do that? Ok, time for an example. I'm sending
you this instruction to use markdown, and I want it to look exactly this:

Heading
===
## Sub-heading

Paragraphs are separated
by a blank line.

Two spaces at the end of a line
produces a line break.

Text attributes _italic_, **bold**, `monospace`.

Bullet list:

  * apples
  * oranges
  * pears

Numbered list:

  1. wash
  2. rinse
  3. repeat


But you'll see this:
Heading
Sub-heading
Paragraph are separated by a blank line.
Two spaces at the end of a line produces a like breal.
Text attributes italic, bold, monospace.
Bullet list:

   - apples
   - oranges
   - pears

Numbered list:

   1. wash
   2. rinse
   3. repeat


How do I turn off markdown processing on your side? I don't even know you
do have some thing that misformats my message despite having no intent to
be misformatted that way. This is especially a problem when someone is
trying to pass parts of computer code or config.


HTML isn't readable, the syntax in 0393 is designed to be readable and
> convey basic meaning whether it gets rendered or not. If you need to
> pass a sample of plain text, you can put it in a pre-rendered text block
> (eg. ```).
>

Ok, I get that 0393's idea of fallback is a user pretending that this
syntax does not cause him inconvenience.


> I see, I misunderstood that. That seems like a lot of complexity for
> clients to implement over just using OOB or SIMS or something similar
> that doesn't involve referencing things in the body.
>

How is it a lot of complexity if it's almost exactly same as SIMS?

I disagree; one changes the style of the message, one is completely
> unrelated. If I style a message by emphasizing some text, any client
> that supports my styling will show it somehow to convey emphasis to the
> user. If I'm sending an image, some clients may display it inline, some
> may just have an attachments pane where users can download files, some
> may show a button or link, etc. It doesn't necessarily affect the style
> of the message at all. Similarly, mentions may be styled differently, or
> they may just trigger a notification. There are all sorts of other
> concerns that are involved with media and mentions that just don't exist
> for basic styling, so I don't think they're the same thing or need to be
> in the same XEP.
>

The key is the word 'may'. Indeed, you may not emphasise user mention in
your client. But if you DO support mentios, would you really NOT style a
mention as something special? I know exactly ZERO services / apps that have
mentions and that don't style mentions in a distinctive way. Twitter,
Facebook, Google+, Hangouts, Slack, WhatsApp, Viber, WeChat, Mastodon,
Identi.ca, Mattermost, Microsoft Teams, Rocketchat, ... Hell, even any
decent IRC client styles mentions!

Also. I might have miscommunicated. I don't want this to be a 'one XEP'. I
actually prefer a polished nested structure, with 'root' XEP defining a
basic  tag, and several specialized XEPs that each define
specialized things like text markup, sending media, mentions, forwards,
etc.

Put another way, just because I want to support bold and italics doesn't
> mean I want to support attaching images.

Me neither. I just want them to be neatly organized easy to digest and
undestand, without gaps and overlaps.



-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Sam Whited]

On Wed, Mar 27, 2019, at 18:52, Ненахов Андрей wrote:
> >  What is the use case for hyper links and who does it benefit?
> 
> They benefit users. You know, exactly that part of equation that XMPP 
> currently lacks. 
> 
> And the use-case is to make human-readable hyperlinks with titles. For 
> some reason, links on this page with a list of XMPP extensions 
>  look like XEP-0001 
> , not like 
> https://xmpp.org/extensions/xep-0001.html 

This isn't an answer; how do they benefit users? How is this better than:

"Hey, here's a link to the XEP we were talking about: 
https://xmpp.org/extensions/xep-0001.html";

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Ненахов Андрей]

> What is the use case for hyper links and who does it benefit?


They benefit users. You know, exactly that part of equation that XMPP
currently lacks.

And the use-case is to make human-readable hyperlinks with titles. For some
reason, links on this page with a list of XMPP extensions
 look like XEP-0001
, not like
https://xmpp.org/extensions/xep-0001.html

[image: image.png]

-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Ненахов Андрей]

ср, 27 мар. 2019 г. в 23:08, Philipp Hörist :

> Hi,
>
> you try to do what 0394 does, but your syntax is way more bloated and i
> dont see any value added, so why not just use 0394?
> ah yes because you seem to think adoption is better if you stuff
> everything into one XEP. I disagree, in fact i think it has no effect on
> adoption at all.
> Implementing "bold" or "italic" in a client is probably 2 hours work,
> displaying an audio or video player inside your chat window, ranges
> depending on your OS and GUI Framework from many days work to almost
> impossible.
>
> For media transfers there is also already SIMS, where is the added value?
>

The added value is removing a mess that there is. I did not say that there
should be a 'ONE XEP', I said that there should be 'one principle'. It
actually makes sense to, say, convert 0372 into root 'reference' and adding
some simple XEPs to address various specific uses of this for different
cases.

Also, for 'there is also already SIMS'. I don't consider XEP-0385 as
something that already 'IS':
 - references deferred XEP-0372
 - biggest example references deprecated XEP-0071
 - no types of media are ever defined anywhere

How do we share an .ogg voice message, 35seconds long, and 0.31MiB size,
and let recipient display that info without downloading that file?


>
> I can see that it makes sense to have a place where it is described how
> everything is tied together, but this does not have to be a XEP, the XEP is
> only the protocol what is put on the wire, if you put everything into one
> XEP it does not help a developer in any way to develop a nice looking, good
> working GUI. (Thats the actual work)
>

Actually, no. Making a nice looking GUI is a much easier problem when there
is a consistent set of rules you have to follow, without ferreting out bits
of sense in a heap of disorganized docs. After creating clients for three
separate platforms, making sense of XMPP XEPs is by far the worst part of
experience.


-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown needed by a modern messenger [WAS One true final way to mark up messages]

[Sam Whited]

On Wed, Mar 27, 2019, at 17:54, Ненахов Андрей wrote:
> Not really. You know what telegram does? Whenever you're presented
> with a link, it makes this URL: tg://unsafe_url?url=
> https://xabber.com/ and when you click on it, you see a warning,
> изображение.png
>
> Extra easy.

That's a good idea; I do wonder how many things would actually do that
though. I suppose if we added them we could always put a note in the
security section about UI concerns.

> Lists and numbers with dots aren't the same thing either. It won't
> look the same and it's the reason why  and  tags exist.

Why not? As far as I can tell that's what most things do: just stick a
center dot on it. In HTML I'm pretty sure most renderers put a center
dot in the before:content area (I don't actually know what this is
called). A client could do this just as easily.


> Because your plain text version does not work everywhere. I somehow
> forgot to mention the abolute worst thing about 0393 as it it's
> written:* now do you suggest disabling processing these * and _ on
> remote end*??

Why would you want or need to do that? They make a good fallback. If
your client doesn't support *bold* it's still obvious that I wanted to
put emphasis on that word when you see plaintext wrapped in *'s.

> XEP-0071 had a decency to have a special  to put formatted text,
> but you suggest acting like Pidgin, which was infamously putting HTML
> code into , whether the guy on remote end wants it or not. Also,
> If you need to pass, say, a sample of text with markdown format, how
> can recipient view it if it'll already be rendered with fancy
> graphics?

HTML isn't readable, the syntax in 0393 is designed to be readable and
convey basic meaning whether it gets rendered or not. If you need to
pass a sample of plain text, you can put it in a pre-rendered text block
(eg. ```).


> The idea was, that *if* a media object does use "begin"/"end", it IS
> presented as a hyperlink within a text (if it's not some kid of
> special tag to show object inline). But if there are NO "begin" and
> "end" attributes, object should be considered as a generic attached
> object. My examples did contain such variants.

I see, I misunderstood that. That seems like a lot of complexity for
clients to implement over just using OOB or SIMS or something similar
that doesn't involve referencing things in the body.


> Because media and mentions ARE a form of styling. They do have other
> functions and uses as well, but they belong to a same class of tags of
> equal level, just like  is equal to  and  in HTML. Take a
> look: изображение.png

I disagree; one changes the style of the message, one is completely
unrelated. If I style a message by emphasizing some text, any client
that supports my styling will show it somehow to convey emphasis to the
user. If I'm sending an image, some clients may display it inline, some
may just have an attachments pane where users can download files, some
may show a button or link, etc. It doesn't necessarily affect the style
of the message at all. Similarly, mentions may be styled differently, or
they may just trigger a notification. There are all sorts of other
concerns that are involved with media and mentions that just don't exist
for basic styling, so I don't think they're the same thing or need to be
in the same XEP.

Put another way, just because I want to support bold and italics doesn't
mean I want to support attaching images. If they're in the same XEP, it
becomes harder for me to implement one and not the other. Having them
separate makes it easier for me to do one or the other and not have to
dig out what bits I need to just do formatting and not media.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Peter Saint-Andre]

On 3/27/19 12:24 PM, Sam Whited wrote:
> On Wed, Mar 27, 2019, at 17:14, W. Martin Borgert wrote:
>> 0393 is not bad, IMHO. It might need two or three additions, esp.
>> hyperlinks, but most typical use cases are covered.
> 
> What is the use case for hyper links and who does it benefit? I
> keep hearing people say they want them, but I don't really
> understand why they're necessary over just auto linking things that
> look like URLs. Thanks.

+1

/psa
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Sam Whited]

On Wed, Mar 27, 2019, at 17:14, W. Martin Borgert wrote:
> 0393 is not bad, IMHO. It might need two or three additions, esp.
> hyperlinks, but most typical use cases are covered.

What is the use case for hyper links and who does it benefit? I
keep hearing people say they want them, but I don't really
understand why they're necessary over just auto linking things that
look like URLs. Thanks.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Philipp Hörist]

Hi,

you try to do what 0394 does, but your syntax is way more bloated and i
dont see any value added, so why not just use 0394?
ah yes because you seem to think adoption is better if you stuff everything
into one XEP. I disagree, in fact i think it has no effect on adoption at
all.
Implementing "bold" or "italic" in a client is probably 2 hours work,
displaying an audio or video player inside your chat window, ranges
depending on your OS and GUI Framework from many days work to almost
impossible.

For media transfers there is also already SIMS, where is the added value?

I can see that it makes sense to have a place where it is described how
everything is tied together, but this does not have to be a XEP, the XEP is
only the protocol what is put on the wire, if you put everything into one
XEP it does not help a developer in any way to develop a nice looking, good
working GUI. (Thats the actual work)

Parsing the information out of the xml is not the problem, stuffing
everything into references makes it not even 1% easier to implement all
that stuff.

Regards
Philipp
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Ненахов Андрей]

ср, 27 мар. 2019 г. в 22:15, W. Martin Borgert :

> Quoting Ненахов Андрей :
> > XHTML is deprecated,
>
> This, unfortunately, is the case. I'm not completely
> convinced of the arguements against 0071.
>

If it wasn't, I wouln't be starting this discussion.


> > and all other proposals are not in usable shape.
>
> 0393 is not bad, IMHO. It might need two or three additions,
> esp. hyperlinks, but most typical use cases are covered.
>

One more thing I'll say against 0393. 0071 and  approach both
have means of fallback for legacy clients.
0393's fallback method is "user should pretend that he does not see * and _
symbols"

-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown needed by a modern messenger [WAS One true final way to mark up messages]

[Ненахов Андрей]

ср, 27 мар. 2019 г. в 21:22, Sam Whited :

> On Wed, Mar 27, 2019, at 16:03, Ненахов Андрей wrote:
> > I'm firmly against imposing limitations such as these on users. They
> > can always check what website was opened by a browser.
>
> At that point, it's too late.
>

Not really. You know what telegram does? Whenever you're presented with a
link, it makes this URL:
tg://unsafe_url?url=https://xabber.com/
and when you click on it, you see a warning,
[image: изображение.png]

Extra easy.


> Also, named hyperlinks are a done deal, it works everywhere.
>
> Where's "everywhere"? I'm not aware of many IM clients that allow you to
> do this.


Well, Telegram does allow it:


> That's not the same thing though. The list will presumably look exactly
> the same (and possibly be seen by the renderer as exactly the same
> thing) though whether you encode the fact that it's a list in the XML or
> not.

Lists and numbers with dots aren't the same thing either. It won't look the
same and it's the reason why  and  tags exist.


> Why bother adding more XML when it's not going to change anything
> and you can have a plain text version that works everywhere, whether
> your client supports lists or not?
>

Because your plain text version does not work everywhere. I somehow forgot
to mention the abolute worst thing about 0393 as it it's written:* now do
you suggest disabling processing these * and _ on remote end*?? XEP-0071
had a decency to have a special  to put formatted text, but you
suggest acting like Pidgin, which was infamously putting HTML code into
, whether the guy on remote end wants it or not. Also, If you need to
pass, say, a sample of text with markdown format, how can recipient view it
if it'll already be rendered with fancy graphics?

> Not really difficult. We've already made it, and it works great. I'm
> > not talking, of course, about inserting media in  style html
> > images in random areas of the text.
>
> This appears to be what the "begin"/"end" attributes in the
> references examples you provide do.


The idea was, that *if* a media object does use "begin"/"end", it IS
presented as a hyperlink within a text (if it's not some kid of special tag
to show object inline). But if there are NO "begin" and "end" attributes,
object should be considered as a generic attached object. My examples did
contain such variants.


> Then you obviously missed the point of my proposal: to have a uniform
> > approach to everything message. The needs of a modern messenger far
> > exceed the simple 'markup' problem. I'd even say that markup is the
> > least of modern messenger needs. Your suggestion is to basically stick
> > to the same disparate patchwork of XEPs that already exists. So far,
> > results of this approach are less than spectacular. I think it's time
> > to test a different approach.
>
> Yes, I'm disputing the fact that we need one uniform way of encoding all
> this very different information into XML. Having OOB and styling doesn't
> seem like a patchwork of XEPs to me, they just seem like two
> fundamentally different problems, which means they have fundamentally
> different solutions.
>
> I do think we should settle on one way to include media, one way to
> include styling, and one way to do mentions though.
>

Because media and mentions ARE a form of styling. They do have other
functions and uses as well, but they belong to a same class of tags of
equal level, just like  is equal to  and  in HTML. Take a look:
[image: изображение.png]


-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[W. Martin Borgert]

Quoting Ненахов Андрей :

XHTML is deprecated,


This, unfortunately, is the case. I'm not completely
convinced of the arguements against 0071.


and all other proposals are not in usable shape.


0393 is not bad, IMHO. It might need two or three additions,
esp. hyperlinks, but most typical use cases are covered.

For anything more complex there is 0071. It only needs to be
resurrected. Like Lazarus.

Cheers

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Message Styling: is it ready yet? [WAS One true final way to mark up messages]

[Ненахов Андрей]

ср, 27 мар. 2019 г. в 20:49, Sam Whited :

> On Wed, Mar 27, 2019, at 15:38, Ненахов Андрей wrote:
> > As for 0393, I think it is flawed in it's essense and does not bring
> > any improvement over 0071.
>
> The main improvement is that it provides a good plain-text fallback by
> default. XHTML-IM clients have to manually include a plain-text fallback
> in the body, which means some clients will support it and some won't.
>

XHTML-IM had a pretty good fallback. True, it duplicated the contents of
the message, but it was hardly done 'manually'. Things done by software are
'automatic' in my book


> The other advantage is that it's harder to mess up when implementing it.
> Almost every single implementation of XHTML-IM I ever saw had trivial
> script injections. The spec was safe, but it was so easy to accidentally
> overlook something, or forget to implement a whitelist that it always
> happened. This may not be a big deal if you're using a safe HTML parser
> on your phone or desktop, but if you're in a web browser or a web-based
> app platform where you have a full HTML parser with scripting
> capabilities this can become dangerous very fast.
>

Please, don't even get me started on the reasoning behind 0071 deprecation.
"nobody is able to safely display HTML so we'll deprecate it outright". Ok,
I stop here.
In short, I don't think the reasoning behind this decision is valid or
justified.


> This isn't markdown (and can't be rendered correctly by markdown
> parsers), so I'm not aware of any implementations that render HTML.


I meant that the only place I've ever seen markdown, it was use to render
something I was looking at with a browser. That means that text marked up
with markdown ended up being rendered with HTML. Which is OK, because HTML
is an established language to mark up texts of any kind. It can be easily
stripped down to mininum and we could call it a day, so using yet another
markup language is just reinventing the perfectly fine wheel.

>  Also, 393 doesn't address all other use cases I've outlined. With
> >  references, we can have a uniform way to add any future functionality
> >  while retaining fallback compatibility at all times.
>
> Yes, that's true. I disagree with the premise that we need a uniform way
> to do all these things though, but we can discuss that in another thread
> since it's not XEP-0393 specific.
>

I'm advocating for a uniform approach because it all addresses the same
basic entity: message. It is wrong to understand it as a stanza. Regular
users don't see it that way and what technology lies underneath. Think of
it as a envelope sent over regular mail. You can put a letter there, but
also a photo, some money, and a flock of your hair tied with a pretty
ribbon. These are all objects of a same class - *things that can be sent*.
And if you'll employ different ways to send similar objects, you're just
creating confusion. XMPP specification is already quite enormous and
inconsistent, and any newcomer faces a great difficulty to even remotely
understand, what happens and how things should be done. I'm trying to make
that learning curve a bit less steep, and also make interoperability less
painful.

-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown needed by a modern messenger [WAS One true final way to mark up messages]

[Sam Whited]

On Wed, Mar 27, 2019, at 16:03, Ненахов Андрей wrote:
> I'm firmly against imposing limitations such as these on users. They
> can always check what website was opened by a browser.

At that point, it's too late.

> Also, named hyperlinks are a done deal, it works everywhere.

Where's "everywhere"? I'm not aware of many IM clients that allow you to
do this. My feelings on this aren't that strong, so a good argument for
why it's needed could convince me, but I can't imagine why a user would
want to do this over just copy/pasting a URL into the client and letting
it be auto linked. Clicking a button, adding a title, etc. just doesn't
seem necessary except maybe in very niche use cases.

> >  For lists I don't really see a point in including markdown. The
> >  client can still add a lists button and just add "1." or a center
> >  dot before each item. No need for extra markup.
>
> Likewise we can use CAPS instead of bold. Who needs those weitghted
> fonts? :)

That's not the same thing though. The list will presumably look exactly
the same (and possibly be seen by the renderer as exactly the same
thing) though whether you encode the fact that it's a list in the XML or
not. Why bother adding more XML when it's not going to change anything
and you can have a plain text version that works everywhere, whether
your client supports lists or not?

Do you think it's a correct assumption that as a user I won't care
whether it was sent with some fancy XML formatting, or whether a bullet
character was included in my actual message? If not I'd love to know
what benefit it provides to the user. If you do agree with that, what
benefit does it provide to client devs to encode the list in the XML? Or
does it provide a benefit to someone else?

> Not really difficult. We've already made it, and it works great. I'm
> not talking, of course, about inserting media in  style html
> images in random areas of the text.

This appears to be what the "begin"/"end" attributes in the
references examples you provide do. If you're not talking about this,
why bother including it in a markup XEP instead of just attaching it
using OOB or similar?

I'm not understanding the benefit of coming up with another way to do
this (If the benefit you see is just having fewer XEPs, read on for why
I disagree, if there's some other benefit I'm missing, I'd love to know
what it is).

> No,only like what any whatsapp is capable of. However, I don't think
> it's beyond our capacity to make a decently looking text even if it
> WILL contain images within. If articles on Medium.com can look
> decently on both desktop and mobile, I see no reason to claim that it
> can't be done.

Oh it can be done (obviously, since the web does it), it's just more
work and a lot of extra complexity to think about for very little
benefit that I can see. I said it was complicated, not impossible :)

> Then you obviously missed the point of my proposal: to have a uniform
> approach to everything message. The needs of a modern messenger far
> exceed the simple 'markup' problem. I'd even say that markup is the
> least of modern messenger needs. Your suggestion is to basically stick
> to the same disparate patchwork of XEPs that already exists. So far,
> results of this approach are less than spectacular. I think it's time
> to test a different approach.

Yes, I'm disputing the fact that we need one uniform way of encoding all
this very different information into XML. Having OOB and styling doesn't
seem like a patchwork of XEPs to me, they just seem like two
fundamentally different problems, which means they have fundamentally
different solutions.

I do think we should settle on one way to include media, one way to
include styling, and one way to do mentions though.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Markdown needed by a modern messenger [WAS One true final way to mark up messages]

[Ненахов Андрей]

Hyperlinks I think we shouldn't include; instead, just let the client
> auto link things that look like URLs.
>
Naming them just adds the potential for abuse (eg.
> [google.com](https://malwaresite.example.com)).
>

I'm firmly against imposing limitations such as these on users. They can
always check what website was opened by a browser. Also, named hyperlinks
are a done deal, it works everywhere.

For lists I don't really see a point in including markdown. The client
> can still add a lists button and just add "1." or a center dot before
> each item. No need for extra markup.
>

Likewise we can use CAPS instead of bold. Who needs those weitghted fonts?
:)


> > Media Modern messengers are capable to send various media, often
> > presenting it as such.
>
> This isn't markdown and doesn't need to be a part of a markdown XEP in
> my opinion. Markdown would be determining where in a message the media
> is presented and how the text flows around it, but this is *very*
> complicated and is hard to make work on all screen sizes.
>

Not really difficult. We've already made it, and it works great. I'm not
talking, of course, about inserting media in  style html images in
random areas of the text. No,only like what any whatsapp is capable of.
However, I don't think it's beyond our capacity to make a decently looking
text even if it WILL contain images within. If articles on Medium.com can
look decently on both desktop and mobile, I see no reason to claim that it
can't be done.


>
> Instead, in my mind, media should just be included using OOB, SIMS, or
> a similar XEP and the client should show it near the message that it was
> a part of. Clients might do this by putting the media before or after
> the message in the same "bubble", or by having some sort of
> "attachments" menu, but that's up to the individual client. Exactly how
> the media is displayed isn't really important in the same way that where
> exactly line breaks occur in the text during soft wrapping isn't all
> that important.
>

Then you obviously missed the point of my proposal: to have a uniform
approach to everything message. The needs of a modern messenger far exceed
the simple 'markup' problem. I'd even say that markup is the least of
modern messenger needs. Your suggestion is to basically stick to the same
disparate patchwork of XEPs that already exists. So far, results of this
approach are less than spectacular. I think it's time to test a different
approach.


-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Message Styling: is it ready yet? [WAS One true final way to mark up messages]

[Sam Whited]

On Wed, Mar 27, 2019, at 15:38, Ненахов Андрей wrote:
> As for 0393, I think it is flawed in it's essense and does not bring
> any improvement over 0071.

The main improvement is that it provides a good plain-text fallback by
default. XHTML-IM clients have to manually include a plain-text fallback
in the body, which means some clients will support it and some won't.

The other advantage is that it's harder to mess up when implementing it.
Almost every single implementation of XHTML-IM I ever saw had trivial
script injections. The spec was safe, but it was so easy to accidentally
overlook something, or forget to implement a whitelist that it always
happened. This may not be a big deal if you're using a safe HTML parser
on your phone or desktop, but if you're in a web browser or a web-based
app platform where you have a full HTML parser with scripting
capabilities this can become dangerous very fast.

> It's OK to use a markdown synthax as a what-you-see-is-not-what-you-
> get type of editor, but to pass markdown code to remote party is silly
> idea. Any markdown processor I've ever seen ends up rendering HTML.
> Why not pass HTML then?

This isn't markdown (and can't be rendered correctly by markdown
parsers), so I'm not aware of any implementations that render HTML. HTML
is *huge* so if you're building a new formatting system why bother
including it? Just go straight from the *bold* to actually showing bold.
No need to go to HTML first. As for why we shouldn't just pass HTML
around, see my previous response and why we obsoleted XHTML-IM in the
first place.

>  Also, 393 doesn't address all other use cases I've outlined. With
>  references, we can have a uniform way to add any future functionality
>  while retaining fallback compatibility at all times.

Yes, that's true. I disagree with the premise that we need a uniform way
to do all these things though, but we can discuss that in another thread
since it's not XEP-0393 specific.

Thanks for the follow up and clarifications.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Message Styling: is it ready yet? [WAS One true final way to mark up messages]

[Ненахов Андрей]

ср, 27 мар. 2019 г. в 20:23, Sam Whited :

> The email this was in response to was *very* long, so I'm going to split
> up some of the things I wanted to discuss into separate threads.
> I didn't want to hijack the original email and make it about 0393.
>
> On Wed, Mar 27, 2019, at 13:20, Ненахов Андрей wrote:
> > All right. There are many ways and proposals for format and markup
> > messages in XMPP. Related ideas are:
> > *XHTML*, as in (deprecated) XEP-0071
> > *Markdown*(ish), as in XEP-0393
> > and two types of position based markdown:
> > *Markup*, as in XEP-394 Message Markup
> > *Reference*, as in XEP-372 and XEP-0385
> >
> > XHTML is deprecated, and all other proposals are not in usable shape.
> > I suggest we concentrate on what a modern messenger needs, and then
> > decide how we can achieve that.
>
> Since XEP-0393 is mine, I wanted to follow up about it specifically.
> What makes you think it's not in usable shape? It's being used in a few
> clients and seems to be working well enough there, but anything that
> makes it unusable I'd love to fix.
>

Usable shape was more referring to 0372, which is half-complete. As for
0393, I think it is flawed in it's essense and does not bring any
improvement over 0071. It's OK to use a markdown synthax as a
what-you-see-is-not-what-you-get type of editor, but to pass markdown code
to remote party is silly idea. Any markdown processor I've ever seen ends
up rendering HTML. Why not pass HTML then?

Also, 393 doesn't address all other use cases I've outlined. With
references, we can have a uniform way to add any future functionality while
retaining fallback compatibility at all times.




-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Markdown needed by a modern messenger [WAS One true final way to mark up messages]

[Sam Whited]

Since the email this is in reply to was rather long, I split out a
thread just to talk about what sort of markdown a modern messenger
needs, the last bit of the original messages was about references in
particular which I think deserves its own separate discussion.

On 2019-03-27, Ненахов Андрей wrote:
> So, what a modern messenger needs ?
>
> Markup
> Obviously, we want to be able to have basic markup:
> *bold*
> *italic*
> *underline*
> strikethrough
> hyperlinks 
>
> > and some quotes

I agree with most of these, except that I don't think underline or
strikethrough are absolutely necessary. I'm not against including them
since they're as simple as bold and italic, but if the author of a
formatting XEP didn't want to include them for one reason or another I'd
understand.

Hyperlinks I think we shouldn't include; instead, just let the client
auto link things that look like URLs.
Naming them just adds the potential for abuse (eg.
[google.com](https://malwaresite.example.com)).
On the web this isn't as big of a problem because web browsers largely
do the same thing and have the same basic UI security considerations
(eg. you can mouse over a link and see where it goes or similar).
Messengers tend to be built by one or two people who have no expertise
in designing a safe UI for their users, and these little details often
get forgotten or aren't even considered a security feature.

Note that I'm only thinking about the messenger use case here; other
uses of XMPP may need links or other formatting that could be in a
separate XEP later.

> Maybe, even unordered and ordered lists. Tables... hardly in the first
> place, but in the future... maybe.

My rationale for not including tables in my own attempt at a formatting
XEP is that tables are very rigid and don't fit well in web pages which
are very responsive by default. IM messages are the same way, if I
resize the window or view it from a phone with a tiny screen, tables
don't always scale very well (they get cut off or become hard to read).

For lists I don't really see a point in including markdown. The client
can still add a lists button and just add "1." or a center dot before
each item. No need for extra markup.

 · this
 · is
 · a
 · list

 1. so
 2. is
 3. this

Maybe this should be mentioned in formatting XEPs so that it's more
obvious to client developers?

> Media Modern messengers are capable to send various media, often
> presenting it as such.

This isn't markdown and doesn't need to be a part of a markdown XEP in
my opinion. Markdown would be determining where in a message the media
is presented and how the text flows around it, but this is *very*
complicated and is hard to make work on all screen sizes.

Instead, in my mind, media should just be included using OOB, SIMS, or
a similar XEP and the client should show it near the message that it was
a part of. Clients might do this by putting the media before or after
the message in the same "bubble", or by having some sort of
"attachments" menu, but that's up to the individual client. Exactly how
the media is displayed isn't really important in the same way that where
exactly line breaks occur in the text during soft wrapping isn't all
that important.

Mentions are an entirely separate issue that I think is worth
discussing, but this reply is already getting quite long.
I do think they're not "markup" and shouldn't be in a markup XEP;
they're complicated enough that they probably need their own document to
explain exactly how you create them, what sort of notifications they
trigger, etc.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Message Styling: is it ready yet? [WAS One true final way to mark up messages]

[Sam Whited]

The email this was in response to was *very* long, so I'm going to split
up some of the things I wanted to discuss into separate threads.
I didn't want to hijack the original email and make it about 0393.

On Wed, Mar 27, 2019, at 13:20, Ненахов Андрей wrote:
> All right. There are many ways and proposals for format and markup
> messages in XMPP. Related ideas are:
> *XHTML*, as in (deprecated) XEP-0071
> *Markdown*(ish), as in XEP-0393
> and two types of position based markdown:
> *Markup*, as in XEP-394 Message Markup
> *Reference*, as in XEP-372 and XEP-0385 
>
> XHTML is deprecated, and all other proposals are not in usable shape.
> I suggest we concentrate on what a modern messenger needs, and then
> decide how we can achieve that.

Since XEP-0393 is mine, I wanted to follow up about it specifically.
What makes you think it's not in usable shape? It's being used in a few
clients and seems to be working well enough there, but anything that
makes it unusable I'd love to fix.

> I suggest we concentrate on what a modern messenger needs, and then
> decide how we can achieve that.

FWIW, this is exactly how I tried to design message styling. It imitates what
most modern commercial messengers do, which seems to be good enough for
most people (and I've never found myself wanting more when using some of
the popular commercial messengers at work). But anything you think it's
missing, I'd love to hear about it.

I do understand that it doesn't cover every single use case in your
original message, but I think it only leaves things out that are better
done through a different XEP, or which I don't think are markup (eg.
attaching a file to a message). I'll write more on that in a general
reply to your message and we can discuss it there. Any feedback you
have on 0393 would be appreciated.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Melvin Keskin]

Hello,

I am the author of Automatic Trust Transfer (ATT).

You can find further information and links in the ATT repository:
https://github.com/olomono/att

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___