Ah, you meant the same post being reshared by many. There we can do one thing IMO - consolidate/summarize the reshared post based on post id. Example - Mr. X, Y and Z reshared Mr.M's post.. So, you'll see it only once (maximum twice - the original post and one summary).
Just my suggestion.

There's already a GitHub issue for this - no need for a vote, it just needs someone to create the code.

I think the neatest solution to presenting multiple reshares in the stream would be to display the reshare at the time of the most recent reshare, with links to 'Reshared by' and the names or avatars of the people in your stream who have reshared that post. Clicking the name/avatar of one of those people would take you to their reshare of that post in single-post view, with the comments made on their reshare.

I think the same as @goob. It could be something like that or showing the reshares folded (so you can open it and read comments with a click).

Question: isn't it too soon to vote something without a brainstorm or a debate?
I think that is not democratic, for example: imagine that I talk with some people, open an issue and a proposal, we vote for what we want and close it as soon as possible.
Remember that using Loomio will not get things going faster. Loomio creates the political decitions, but not the development.

There are guidelines for using Loomio here.

It might be better to find a way to collapse reshares into a single post if you've already seen the post. The trick is figuring out how to accomplish that.

Something I had in mind for a wile.

The reshares quantity is sometimes huge in the stream. Group them causes the following problem : one don't know, when commenting, if he is commenting the original post or the reshare.

I've made this observation: frequently, when people reshare, it is just to spread an information. Hence, people oftenly want to comment it but want to comment the original.

The other point is that, a frequent asked question is that it is possible to modify a reshare (add text, or something). The answer is no, though there are scripts to enable this.

My idea is the following: there should be two type of reshare:

• the original one : simple reshare, no modification; the post is the same, it is displayed only once in the stream, all comments mae on a reshare are merged into the original one.

• the augmented reshare : this create a totally new post; one can add text above the original post, change the confidentiality, comments are separated from the original post.

The only thing I don't know is how difficult would be this to code ? I think this could be a part of the milestone for the next release after 0.5.

+1 for original resharing.

@augier : I like your idea of double share! Efficient way to address many annoying issues.

I suggest original reshare could be renamed as spread and augmented reshare as reshare (since people are used to it because of other networks) or repost (to make more obvious that some modifications are possible).

And maybe a pop-up with a click box "don't show next time" could explain things to make them clear to new users.

Ohh... Markdown doesn't work in proposals? Sorry for the poor rendering. Does someone know how to change that?

I like the wording ! :D

Apparently Markdown is not supported in proposals... :-(

Here is the description properly displayed:

Following the comment by @Augier I propose to split the reshare function into 2 ones:

• Spread a message. This would correspond to the current reshare, modified such as likes and comments would all be aggregated to the original post (no new message, see comment by @Flaburgan on github ).
• Repost a message. In this case a new message would be created, you would be able to add your own text/mentions on top of it (see here ). likes and comments should not be aggregated in this case.

In both cases we could be able to choose some aspects instead of public, as asked in this other thread.

Nice work @globulle, I love when the democracy-machine starts turning! :D

Still wondering if this would fix the stream-flooding-issue tho, cause spreads could still pop up by the many, if you get them by tags or they're spread by several of your contacts. That github issue imho still needs attention.

@es Yes, you're right. Maybe the button to not be notified anymore (already present, the "bell" one), could also prevent the post to pop in your stream from further spreads...?

Still wondering if this would fix the stream-flooding-issue tho

Should be. Spread messages (previously reshared) would be aggregated into one as it would be the same post.

To make it more clear : a spread message should appear only one time in your whole stream. But it would be on top of your stream every time a friend of yours would spread it. For exemple, if A and B are two people I share with :

• A spreads it a first time yesterday, so I may have seen the post.
• The message is getting lower and lower in my stream as new feeds arrive
• B spreads it today: the original message will then appear in my stream at this date, so upper than its original place in my stream .

I don't see it as a problem, since it tells you how popular it is, and may help draw your attention on this if you missed it the first time (the purpose is actually to spread, in this case). But this behavior can become annoying if the message gets stuck on top of your stream because it is spread by many. That's why I suggested the possibility to "unfollow" it to avoid seeing it again when new spread occur.

In both cases we could be able to choose some aspects instead of public

Currently all participations on public posts are public.

1. Do you want reshares to be private participations on public posts or should reshares be separated from the post?
2. How do you handle those two new kinds of interaction? Should both be added to the list of reshares of the post? (This is strongly related to the first question)
3. Are those cases ok, where the original author is not allowed to see the reshare of their post?

Do you want reshares to be private participations on public posts or should reshares be separated from the post?

Meh. I could have answered this myself if I would have thought about it. Private participations are not possible since the author doesn't know who is allowed to see the reshare and in some cases even the author doesn't know about the reshare so this means that we would have to separate reshares from the original post.

In the case of repost, as it would basically be a new message which quotes the original one, it makes sense to me to choose the aspect you want to address it. I don't think these reposts have to be counted as reshares on the original post. It could be as if you wrote a new message with the link to a public post (something I personnally often do).

In the spread case, if the spread is public, it would be counted as the current reshares. If the spread is private, I suggest to not count it at all, or to add a private reshare (anonymous) count. This could inform public and the owner its message has been passed on.

Concerning your point 3, in my opinion, when you post something as public, you implicitely accept to lose some control over it. The original author would keep the right to supress it (with all dependencies), but would accept to not know all the reactions its post generates (which is already the case, since you can reshare it as a simple link).

I don’t think these reposts have to be counted as reshares on the original post.

Do we have a link to those reposts in the single post view? Does the original author get a notification if the repost is public or the author is allowed to see the post?

if the spread is public, it would be counted as the current reshares. If the spread is private, I suggest to not count it at all, or to add a private reshare (anonymous) count.

In which cases do we notifiy the original author?

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.

just saying ‘somebody has spread your post as private’ when this is not [public].

How do you want to do that in a decentralized network?
Say user A on pod A spreads a post by user B on pod B. How should pod A tell pod B that the author should be notified? (pod A could be a pod with only one user) We have the same problem when we would like to display the number of private reshares.

I don't get it... Why should it work differently than the current reshares?
I am user A on pod A, you're user B on pod B. If I reshare your post, you are notified. Now if I spread it privately, the only difference is that your notification would be "One people has spread your post in private", instead of "User B has reshared your post". Where is the point?

How can you spread privately when all likes and comments from your private spread go to the public original post?

Currenty reshares are always public. When we allow private reshares we have to make sure that also the existence of the reshare stays private. When you notify the original author, even if you are not sharing with them, then the author knows that a user on pod A reshared their post and when the pod only has one user then it is even obvious which user reshared the post.

@supertux88 Note that a spread is just a way to show a public post to a group of people. It's basically the same as writing a private message with the link of a public post and asking people to like/comment on the original one...

@steffenvanbergerem Your scenario is relevant in the case the original author know the pod of the person who reshared privately, if I get it right. But why would he know that? The notification should say 'someone', no mention of name or pod. It could be anyone from the whole D* network.

@globulle So you would like to send the notifications as unsigned messages through the TOR network? Otherwise it is easy to find out which user reshared the post.

1. AFAIK we sign all messages that we send from one pod to another.
2. As a podmin you know which server sent you a message.

OK, I get it. I was standing from the simple user point of view, not the hacker who knows how works the pod. Then it's much more difficult for me to answer... If I understand clearly : the problem is : how to send a notification whom the provenance cannot be tracked? hum... joker ! :-) TOR seems a bit too much, doesn't it?

Just an idea I deliver as it comes:

We could use another pod (chosen randomly among the 10 bigger ones for example) as a relay to send the notification. Thus, from the receiver point of view the source would not mean anything.

Maybe too instable/complicated?

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

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

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.

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

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

Steffen++

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.

You are probably right.

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