@juansantiago what's the syntax used by RedMatrix?

Redmatrix uses a kind of BBcode itself, but I haven't managed to get the integration with diaspora work and to see what comes to our side.

@comradesenya I think you should detail a bit the pro and the cons of the link syntax ([]()) versus the embedding syntax (![]())

Well, actually ![]() is not a standard and not even an extension. The CommonMark people are still discussing the syntax as we do. And they have alternative proposals like !audio[]() syntax. I also have an idea just now come to my head - to use text inside the square brackets to mark media type like ![embed:audio alt_text](url).

I'll try to sum up details a little bit later.

The link syntax([]())
pros:
Will look nice even with software, which doesn't support embedding.
cons:
Will be unable to post a link without embedding.
The image syntax ![]()
pros:
The syntax is unambiguous if the software supports it. Proposed and used by somebody in the CommonMark community.
cons:
Looks bad if used with unsupported software (e.g. older versions of diaspora). Require more work to deal with tumblr export and mobile versions of diaspora.

cons:
Will be unable to post a link without embedding.

What do you mean?

I mean, that if you post [title](http://example.com/file.webm), then it'll be replaced with embed, and you can't have it as a usual link.

Ah ok, that shouldn't be a big issue I guess.

But still, I think I prefer the consistency for towards image embeds, so I'm voting for that.

We could use the link syntax until there is an approved standard. Switching to the standard later would display the embedded audio/video files as links which should be fine.

I'll vote with "Yes" but I'll only support this proposal until there is an approved standard.

I think loosing possibility for the user to format himself the message (he can't choose anymore whether he wants to embedd or link) is not worth.

Someone else proposed an alternative syntax: ~[]() for audio and #[]() for video. ~ representing audio wave and # representing video image.

Seems controversial, I'd say let's extend the voting time a bit.

I've extended it for 24 hours more.

Well, I don't know the usual voting procedure, but since we don't have any blocks and the majority agrees, maybe we can consider it accepted? I mean, if a voter is strongly against the proposition, the he votes for block which means we can't accept it. And if it is just "disagree", then IMO it means: "I disagree, but I'm OK if majority is opposite".

Alternatively, we could conduct another voting for the image syntax and see, what happens.

I've detailed a bit more my implementation for inline image-like video/audio embed.

http://blog.podricing.pw/multimedia-support.html

@comradesenya I usually try to include two full weekends, but yeah, looks like this will pass.

@nolcip note that this proposes to do what your script does essentially, just for []() instead of ![]().

I just want to highlight that, []()has been proposed to manage incompatibility with old versions but, if later ![]() syntax is adopted in the standard --- which has great chances to happen, as it is syntactically more logical --- you are in any case creating an incompatibility. Plus, people will be used to []() syntax to embed audio and video medias and they'll have to change their habits again. This look really an awful solution.

I wonder if this passes how we are going to communicate this this to users?

So to make links, do [](http://uri). Except if that uri is a video of certain types, it will embed it. To embed images, use ![](http://). Why? Lol.

Confusing? Yes :)

@jasonrobinson, on the other hand, adding a link in the []() way is how people post links to audio/video URL sometimes (example example example). Because it is natural as well, while not having a possibility to use special embedding syntax to post just a usual link.

I wonder why can't we vote for several proposals at the same time here, it would have been handy.

Maybe supporting both syntax type simultaneously? Yes, we will lost a possibility to post a simple link to a media file, but nobody really needs it. If you have a media player - you can download a media file with a right click. You hardly want to have such link, so not a big issue IMO.

I just noticed, that posting a bare link without any syntax (just https://......) produces an embed as well (appears that Diaspora replaces it with a link []()). And that makes good sense as well, because it is similar to how the youtube embeds are done.

So maybe not that confusing and contradictory as might seem?

Mmmh, actually why don't we only autoembed for bare links for now? That would be consistent with the oEmbed embeds.

@comradesenya

I just noticed, that posting a bare link without any syntax (just https://……) produces an embed as well (appears that Diaspora replaces it with a link ). And that makes good sense as well, because it is similar to how the youtube embeds are done.

This is totally unrelated. It is not an embed tag that does this, we just do an embed or preview based on the first url in the post. The user has no control whether this happens or where it is rendered (at the end).

TBH, if we can't use the same embed code as for images then lets not please use any at all for some hacky short term solution that will only confuse users.

Also, before auto-embedding the first link for audio and video, it should be then taken into account is it a good idea then to use any tags for direct embedding? Because in this case it would mean embedding it twice for a post with a single audio element, for example.

So to make links, do . Except if that uri is a video of certain types, it will embed it. To embed images, use . Why? Lol.

Isn't that exactly what happens currently? Except this proposal will extend embedding to more types of content?

I'm not going to vote on this as I don't have a strong feeling so will leave it up to those of you who understand the technical side of it better!

Isn’t that exactly what happens currently? Except this proposal will extend embedding to more types of content?

No, this proposal would mean that []() would embed in place content, not create a link to it, like happens now.

I think I won't extend the voting anymore. If you are really against the link syntax, please block the proposition.

Imagine what will happen, if they would accept something different than ![]() as a standard (and consider it as the image only syntax)? Then we'll have to change it, and everything in the past will get broken. With links it'll at least look nice. (and we still don't have a post edit feature, so nobody can fix the old posts).

@comradesenya we consider a block as no only here. So I think it makes sense to extend it for a week more at least since it is so close.

Ok, I've extended it till the next Monday.

Mmmh, actually why don’t we only autoembed for bare links for now? That would be consistent with the oEmbed embeds.

You just completely loose formatting possibility. It's a huge step backward.

Imagine what will happen, if they would accept something different than ![]() as a standard (and consider it as the image only syntax)?

Well there's two solutions: they adopt ![]() and by choosing []() you are creating an incompatibility and by choosing![](), you are not. They choose, let's say ~[]() and #[]() and in any case you are creating an incompatibility. So I let you deduce which one is safer.

The standard markdown image posting has to stay but, we could use more direct embedding options.

There won't be a limitation to one video. Personally I see this limitation weird - we have to give user wider possibilities and not restrict him.

Ok, now we have a block. If I understand the process of voting correctly, this means, it wouldn't pass. What should we do now? Shut the voting and conduct a new one?

Sorry for the mess. I'm doing it all for the first time.

It would be better to actually discuss Augier's points about incompatibility and alternative ideas for syntax, and see if a decent compormise can be found before starting a new proposal.

The only decent decision is to wait for CommonMark to adopt a standard. Every other option is an attempt to guess the future.

@comradesenya https://www.loomio.org/d/DGjvERsx/blocked-proposals?proposal=Wrow8KAk

No, this proposal would mean that would embed in place content, not create a link to it, like happens now.

Try providing a link to e.g. a YouTube video using []() syntax - it'll embed it. This already happens with a number of sites.

If you mean that embedded content will in future be displayed at the exact point in the post at which the link was entered, I didn't see anything in the proposal specifying that.

This proposal is not to discuss a place for the embed. The code is
written already, and it embeds in-place.

This proposal is to discuss a syntax for that to happen.

Hey guys!
While some of you are in Paris together, maybe you find time to discuss the matter live? That can be productive.

This proposal is not to discuss a place for the embed. The code is written already, and it embeds in-place.

The embed in-place is a bit of a blocker for using the link concept. This will really break posts where the user only wants to link, not embed. Sorry, I feel this is a bad way to go forward.

Why not make a simple proposal about whether to embed in place or the first one at the end?

Why not make a simple proposal about whether to embed in place or the first one at the end?

++

Hmm no actually I think this makes sense, kinda. Youtube type of embed at end of post should be done whenever a link is posted to the resource, be it either plain paste of link or the link format [](). And for embedding in place, ![]() should be the format for whatever embed in place, be it images, video etc.

This is how things work now, except it would be nice to also embed the first image of the post to the message if it is not using the embed syntax, just not in place. This is how for example Facebook works (except they don't support embed in place).

One might even consider completely dropping the automatic embeds at the end of a post. Instead users could define themselves, which content should be embedded and where it should be displayed: via Markdown if we embed in place. This would of course mean that we use some syntax which is different from the link syntax.

Someone mentioned
@[]() for audio embeds and
^[]() for video embeds here.

I am not saying that we should definitely adopt this (haven't decided on my favorite proposal yet) but I wanted to drop this here as another possible syntax.

@trekkie we're discussing the "regular user" vs "markdown" problem in the thread about the publisher, and we will solve it don't worry, let's not discuss about that here and stay in topic ;)

So, instead of guessing, what about being involved in common-mark and try to take a decision with everybody there?

One might even consider completely dropping the automatic embeds at the end of a post.

All of them? Including website abstracts and YT embeds?

So, instead of guessing, what about being involved in common-mark and try to take a decision with everybody there?

Yep, this is a goo idea.

Just add it to the end of the post like Youtube - no proposal needed for that imho since it doesn't break any existing posts. Once CommonMark agrees on a standard we could embrace that then.

Well, I don't like the idea of embedding in the end of the post at all, but that wouldn't be such a big problem if it didn't require full reimplementation of 6418.

I read all the comments (pfiou!).

To me, there are two distinct ways to embed a media:
1. Interpret the first link (raw or []()) and embed the media at the end of the post. This is what FB, G+ and Twitter do
2. Use a specific syntax saying that you want to embed something (could be ![](), but I've got some concerns about that, see below). Being able to choose where to embed media in the post is a unique and useful feature D*

I don't think []() should be used to choose where to embed media. So, that would be a no for me.

About the ![]() syntax, that would be extremely cool that one syntax could regroup all the embedded media types, but that depends on one big condition: is it possible/wanted to detect the media type dynamically?

If we decide to use a common syntax for all the media types (image, audio, video), it seems to break the principle of the Markdown syntax: one statement = one HTML tag. Here we would have one statement that could be translated into either , or . Is it even possible?

I personally think that ![]() is error prone and unacceptable.

I also strongly beleive the media should be embedded in-place, not in the end of the post. If someone doesn't agree, let's discuss it or create voting proposal for that.

Here was proposed an idea, that we can embed media which are the only element in paragraph and leave them as links where they aren't. The main complaint about link syntaxt was that it didn't allow to decide whether to embed or not. And thus it'll be kind of solved.

So if I write

blablabla

[text](link.webm)

blablabla

It'll be embedded. And if I write blablabla: [text](link.webm) it won't.

So if a user wants to show link but not video, he just has to add some text on the same line with the link. It'll require quite a rewrite of my related PR, but I'm ready to to that, if we agree upon the idea.

@jasonrobinson, I would prefer embedding with the link syntax, but only in case when the link is the only element on the paragraph. That won't be confusing, right?

Yes I think it is confusing if it doesn't work like images do. People are already used to ![]() - why should embedding in place anything else work any differently? That would be confusing for users, there already is two ways to embed things:

• in place with ![]() for images
• end of post for anything that support oembed

Having a third option for audio etc would be confusing.

Looking at the discussion at commonmark it looks like ![](http://example.com/song.mp3) will become the syntax, even if nothing is really acted yet.

I think it's important that diaspora only accept audio and video content that's delivered over https because of the security reasons.

but why that? we r terrorized allover, stations closed, journalists delivered, tortured & killed, paranoia is immanent in the subject and that's why I vote against that-> frankly, I don`t believe in that "standard and rather would use kind of ISSecAuth:? :sweat_smile:

I'm all for a good handling of the media formats in our posts and the possibility to choose the layout of it.

Personally I'd prefer not to have the auto-embedding feature. I'm sure that a good "post editor" can easily replace this feature.

Imagine that if you type a link with the syntax [](), the post editor detects that it is a mere link to a page or a link to a media type, and then propose you to switch the syntax with ![]() and vice-versa.

For information, gitlab allows to embed video and it uses the ![]() syntax, see the Gitlab Flavored Markdown doc.