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.
@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.
@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…?
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.
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.
Proposal: Splitting Reshare into Spread and Repost
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.
Outcome: The current proposal has been accepted by a wide majority. Some technical issues need to be addressed though before its implementation. This could be done when federation code separation will be achieved.
Votes:
Yes: 13
Abstain: 0
No: 0
Block: 2
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
@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.
AFAIK we sign all messages that we send from one pod to another.
As a podmin you know which server sent you a message.
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.
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?
In both cases we could be able to choose some aspects instead of public
Currently all participations on public posts are public.
Do you want reshares to be private participations on public posts or should reshares be separated from the post?
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)
Are those cases ok, where the original author is not allowed to see the reshare of their 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.
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.
@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.
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?
TOR seems a bit too much, doesn’t it?