Allowing people to easier link to/reference posts in their own posts

In case of spreads, I think the original author should be notified each time : with the name of the user when it’s public, or just saying ‘somebody has spread your post as private’ when this is not.

In case of reposts I have more doubts, but we can do basically the same. The important point is to keep notifying the original author when it’s public.

@steffenvanbergerem : what do you think about my previous comment? Does it seem feasible?

@es I think notifying the original poster as before would induce some problems regarding privacy, since it gives a public visibility to a private action. I presume somebody who posts to specific aspects only should not let any signed public print.

But I mostly agree with your message since this issue can be solved the other way: not notifying the original author at all, as long as there is no satisfactory solution. Which is basically what happens when you post the url of a public message to specific aspects (something quite frequent I suppose).

To quote @steffenvanbergerem “When we allow private reshares we have to make sure that also the existence of the reshare stays private.” Why? If this is the only issue and would make things overly complicated, just notify the original poster as before. The term ‘private’ may be misleading here, but this ist not about secret resharing, but limited resharing to certain aspects. Therfore I strongly disagree with your veto, throwing us right back into waiting forever and nothing happening about issues people have been going on about for years. It is never to early to take about changes, no one expects them to be implemented tommorrow or even in the next months.

@globulle No. This will make the federation much more complex and since there would be an additional step this would also increase the probability of undeliverable messages. Also that extra pod that you choose still knows too much and could also decide to deliver no messages for other pods at all.

All in all I think that the changes you proposed will make the federation too complex and I’d like to see a proposal where only public reshares are allowed to spread a post.

But before creating yet another proposal I think we should wait until we completely moved the federation to a gem. Changing the federation is currently not an option for me and I think you won’t be able to find any core team member who is willing to merge federation changes in the d* code itself.

I guess @supertux88 already has some ideas how he could improve the federation protocol after he completely moved it to a separate repository and I guess he is also willing to improve the way reshares are federated.

I’ll block this proposal because I think that there are currently no adequate answers for important questions about this proposal and that we need some time to find out what kind of changes would be feasible.

You are probably right.

Let’s separate the federation code from the d* core code before talking about federation protocol changes.


Well, the fact that we are not going to do it right now doesn’t mean we can’t discuss this, does it ?

Sure we can discuss. But while moving the federation to a gem @supertux88 might have some ideas how to improve the federation and might also have some great ideas about reshares so I think this is not the right time to vote. The current proposal has some flaws and I don’t think that there will be an implementation of this proposal which is good enough to merge. Since we won’t change the federation right now we could instead share some ideas and open a new proposal as soon as we are able to change the federation.

Short question. Is it easier to split it into reshare and quote like some script it do? There will be no change into the federation, only into the frontend.

Short question. Is it easier to split it into reshare and quote like some script it do? There will be no change into the federation, only into the frontend.

That could be done. But this look like a dirty patch. better do things right.

No dirty hacking, better make it right in the first place. :slight_smile:

1 Like

So, it looks like this is coming, as it is a really big change in the way diaspora* is used, I feel like we should ask the community before starting to work on this (even if @supertux88 already started to work #83, #84). I prepared a small diaspora HQ message with a poll, keeping things simple and redirecting to discourse for a more complete discussion. We need to choose the wording before posting it.

The reason I split this discussion from the original “collapse reshare” is because of diaspora_federation#82 and the related discussion on IRC.

In short, it was suggested by a PR to add a text property to the reshare entity. The main reasoning behind this was to enable people to add “their own comments” to a reshare when resharing them. Right now, some folks add a comment below their reshare, and some use a weird userscript that quotes the enire post. Both cases are less than ideal for obvious reasons. Adding a “text” field to the reshare would make this easier.

However, in my opinion, this is a short-lived workaround.

It is true that adding this property could solve the initial problem, but I see some obvious limitations. For example, when resharing a self-drawn comic, I might want to add my own comic as well, but I only have a text field available. Even worse, while talking about aggregating reshares in the stream, supporting “customizing” the reshare makes combining reshares even harder, since we’d have to handle “plain reshares” and “reshares with text” differently and somehow come up with an interface that shows both the plain reshares and the individual comments by people. So with adding text to the reshares, we’d solve half of an issue by creating 3 new. Not good.

Instead, I propose two things.

  1. Leaving reshares as-is: a simple reference to another post, without anything fancy. After we solved the current discussion, I will propose removing the ability to comment/like/reshare on reshare instances. This would means that all comments, likes, reshares are always at the root post, not at the reshare. There are some implications to that and this might be a controversial thing, but it’s the only way we can ever aggregate reshares. However, this is not entirely the scope of this dicussion, and I will start this discussion when the time is right (i.e. after we’re done here).
  2. Inventing a way to reference posts, effectively creating a logical link between two posts without directly affecting each other. I will explain in detail.

Below is my proposed solution, with an implicit request for comments. Since this is a fairly complex topic, I will actually be using subheadlines here to make the text easier to navigate and reference. (I guess that’s a first for me!)

Please note that this has some unfinished work in it, this is not considered a “final implementation spec” or something, but merely a starting point. Also, I didn’t do any grammar- or spell checking, and the first version was drawn late at night. So sorry for painful errors.


Our users want a way to distribute a post while also enriching it with their own opinions and ideas. This proposes a way for users to create a post themselves, allowing them to do everything they can do in posts, while clearly linking the new post with another item. This is neither an addition nor a replacement to our current reshares.


For the lack of a better word, I will talk about “referencing posts” in this proposal, where the links between posts will be called “references”. In the initial post, “reshare” and “augmented” reshare" was used, which I find hard to understand. Also, “repost” and “spread” was a suggestion, which I find highly ambiguous. “Referencing” is not perfect and I am aware of it, but I did not manage to come up with something better.


With the support for diaspora:// prefixed URIs on the way, we will have an easy way to reliable reference posts, no matter what pod they are on. Basically, this means we will be able to use diaspora:// soon and no matter what pod this URI is received by, there is a clear way to both retrieve the post and display a link to it. In addition, diaspora pods will automatically transform local HTTP URIs to those diaspora URIs when applicable.

So, I propose to make linking to posts a bit more powerful. When a user posts a link to a post, we should act upon that. Besides linking the post, we should highlight that link somehow.

In addition to make the “link” more meaningful, it would be cool to implement some kind of trackback like feature. That is, if someone links a post, the author would get a notification saying “Alice linked to your post ‘Foo’.”. In addition to the notification, this would allow us to show all posts with references to it below that post, similar to the list of likes and reshares. This would allow the original author of a post to keep track of reactions to their post, while allowing people to share the post around along with their own ideas and comments.

UI and UX

Initially, I was thinking about building a inline-preview like we do for YouTube videos or tweets to show a post preview. However, as I now have slept a night and thought about this idea, I don’t think it is necessary. Instead of showing the URL, we could replace the URL with something like “Post ‘Foo’ by Alice”, and maybe prefix the link with a diaspora icon or something, so we have a clear visual identification that this is “more than a link”.

Building a “preview” is still an idea, but UI could get hard. How do we display references if there is more than one referenced post? How to we handle posts with inlined media? Maybe an idea is to build something similar to our hovercards, where a small preview of the post is shown. However, this has some issues, see below.

Also, we have to figure out how to make it clear that this is a possibility in the first place. One idea is to add another link besides the “resahre” button, maybe opening a popup with “Just copy this link to your post”.

Privacy considerations

While having links between posts would be awesome, it creates challenges to retain privacy and content control here. Therefore, my current idea is to…

  • … not build any kind of previews if the link target is private. If we usually replace the displayed URI with the title and the author, we can either replace that with “a limited post” or simply show the URI.
  • … not “call back” if the post referencing another is a private one. We still can build previews and titles if the target is a public post, but we should not make the containing post trackable in any way.

Unresolved issues

  • What happens if someone uses markdown to link to a post? How do we display it?
  • How do we inform the user that a reference will be made?
  • Should we offer a way to disable that on a per-post basis? If so, how would this look like?

If we decide to build a “preview” for referenced posts:

  • How do we decide whether to show the contents or not in case of someone linking a private post?

A quick reply from me. Perhaps I’ll come up with a longer answer, but for now some quick points that I feel saying right away.

I was thinking about building a inline-preview like we do for YouTube videos or tweets to show a post preview. However, as I now have slept a night and thought about this idea, I don’t think it is necessary. Instead of showing the URL, we could replace the URL with something like “Post ‘Foo’ by Alice”, and maybe prefix the link with a diaspora icon or something, so we have a clear visual identification that this is “more than a link”.

I think that we actually need embedding previews for referenced posts. Otherwise it won’t feel like we have implemented “reshares with own notes” or “private reshares”. Linking posts is actually possible right now using links without hostname [text](/post/:guid), and without the preview it doesn’t feel like anything similar to reshare. I can imagine someone will still want to use “weird userscripts” if we don’t implement proper embedding for linked post. If we are afraid of posts view getting messy, we can make it foldable, similar to like it works for #NSFW posts right now.

What happens if someone uses markdown to link to a post? How do we display it?

Just a short note: if you’re talking about []() markdown, then markdown-it parser which we use for rendering actually doesn’t make difference between plain links and []() links (it creates the same types and set of tokens), so that how we should parse it everywhere, I think.

Thank you @denschub for taking care of writing this up!


Spread was about the clean reshare without like or comment. What about Quote?

I don’t like “quote” ether, since, depending on the implementation, we might not end up quoting the post at all. We may show an excerpt, just a link, …

I agree with senya here, the original/linked/referenced post should be embedded similar to how it currently is with reshares.

I think we should do it the same way as we do it for youtube link, or any other link: Only embed the first referenced post.

In my opinion that wouldn’t feel like a finished solution again. I think opening a popup with the publisher with already the link in it is better. People can still copy/paste the link to another publisher where they already wrote text or when they don’t like to write the post in a popup.

That shouldn’t be a problem, at least normal diaspora:// links should work with markdown like http:// links do. It needs to be discussed/decided if we only embed it when the link is on it’s own line. When we only embed it when it’s on it’s own line we can maybe also embed it inplace (like discourse does it when you post a link that is “oneboxed”). That would also solve the problem when somebody posts multiple links.

By displaying the embedded post in the preview? Or what do you mean?

I don’t understand that question? You mean if we should disallow to link to a post? Or if the author who references a post should disable if it’s embedded? I don’t think we can disallow to link to something.

I think that’s simple, just check if the current user is allowed to see the linked post?

I think we should just call the “spread” case “reshare”, because that’s what it is, and that’s what people already know?

For the new case: If we use diaspora:// links then I think “reference” is OK.

I also thought about using a new message for federating it, that would be similar to the current reshare message. I would have used “quote” then. But that would be much less flexible than diaspora:// links. You could only quote one post, and add a text to it. The only advantage of this would be, that it’s much easier to migrate legacy reshares (with comments and likes) to them, because it would really be similar.

But when using diaspora:// links I think we can just convert all legacy reshares to status messages and set the text to just the link to the original post.

Maybe we could actually use oEmbed to fetch the representation for embedding diaspora:// links? This way it would be easily reusable by other services.

1 Like

+1 for embedding, but why do it similar to reshares? I would go for the oEmbed way with embed in place, like for tweets:

That way we can have a rich embedding, with post interactions etc.

No, I think we should render it ourselves. oEmbed fetches html from remote servers, so we would display html from every pod, that would end in XSS problems (we currently only support oEmbed from trusted domains). And we can render it uniform (so referenced posts look always the same), and we can just render friendica posts like our posts instead of needing to fetch the rendering from friendica.

What is the problem with it? With similar I mean that is should be embedded (instead of only displaying the title), with this gray line at the side, so it’s clear it’s “quoted”, and with avatar and timestamp to link to the original.

Tweets are not embedded in place, they are embedded at the bottom of the post, like everything else that we currently embed.

But as written, we could embed it in place, but only if it’s a plain link on it’s own line (like it is done with onebox here on discourse).

No, I think that would overload the embedding. Like would maybe work, but where do you display comments? How do you handle writing a comment to the referenced post? And having only the possibility to like looks weird.

I also wouldn’t embed oEmbed stuff from the referenced post, that would overload it too. Only the avatar of the author, the name of the author, the timestamp and the content … Everything else can be done on the SPV of the referenced post.

1 Like