Loomio

Reshares

T
Thor77 Public Seen by 402

Its really annoying to see a post sometimes five times in a row. There should be an option to show posts only one time or only one time a day.

T

Thor77 started a proposal Sat 5 Jul 2014

Option Closed Sat 12 Jul 2014

Show an option to show every post only one time or one time a day/week.

Agree - 6
Abstain - 0
Disagree - 6
Block - 2
14 people have voted (9%)
T

Thor77
Agree
Sat 5 Jul 2014

AKS

Akhil Krishnan S
Agree
Sat 5 Jul 2014

Better show original author & a single line specifying who all reshared this.

BC

Balasankar C
Agree
Sat 5 Jul 2014

Summarize the reshares of the post based on post id. Example -
Mr. X, Y and 2 others reshared Mr. M's post.
Or something like that.

A

AlexB
Agree
Sat 5 Jul 2014

I agree with the solution as phrased by Balasankar C and Akhil Krishnan S.

CG

Christian Giménez
Block
Sat 5 Jul 2014

It's too soon to vote for a proposal. @goob said that there's an issue already at github, we should check it before voting (if so, we can go directly to development).

We need a debate first!

JH

Jonne Haß
Disagree
Sun 6 Jul 2014

I see no benefit in making that configurable, it just adds unnecessary code complexity. Also a way more detailed proposal would be good.

N

NicoAlto
Disagree
Sun 6 Jul 2014

DU

[deactivated account]
Block
Sun 6 Jul 2014

Too early for a proposal

EG

Erwan Guyader
Disagree
Sun 6 Jul 2014

RF

Rasmus Fuhse
Disagree
Thu 10 Jul 2014

I have no idea why we need this option. We simply need to solve the issue. If you want to code it Thor77, then go ahead!

B

bh
Disagree
Thu 10 Jul 2014

Need more elegant solution. It's important information - which news liked to my friends, and which news they want to share with me. And comments is very important information too.

PS

Pawel Sroczynski
Agree
Thu 10 Jul 2014

M

morgenstern
Agree
Sat 12 Jul 2014

I agree as far as it's a an option.

G

goob
Disagree
Sat 12 Jul 2014

I think there are better ways to do this, for example by aggregating reshares into one post with links to resharers.

BC

Balasankar C Sat 5 Jul 2014

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.

G

goob Sat 5 Jul 2014

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

G

goob Sat 5 Jul 2014

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.

CG

Christian Giménez Sat 5 Jul 2014

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.

G

goob Sat 5 Jul 2014

There are guidelines for using Loomio here.

ST

Sean Tilley Mon 8 Sep 2014

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.

A

Augier Fri 27 Feb 2015

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.

DU

[deactivated account] Sun 1 Mar 2015

+1 for original resharing.

G

Globulle Tue 3 Mar 2015

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

G

Globulle started a proposal Fri 24 Jul 2015

Splitting *Reshare* into *Spread* and *Repost* Closed Sat 8 Aug 2015

Outcome
by Globulle Tue 25 Apr 2017

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.

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.

Agree - 13
Abstain - 0
Disagree - 0
Block - 2
15 people have voted (9%)
G

Globulle
Agree
Fri 24 Jul 2015

A

Augier
Agree
Fri 24 Jul 2015

E

EsΠ
Agree
Fri 24 Jul 2015

Sounds lika a solid and useful reform.

F

Faldrian
Agree
Fri 24 Jul 2015

Talking of this for years...

I would name it differently: "quote" and reshare / repost (on twitter it is "retweet", so "re"-~ should be the «reach more people» option)

EG

Erwan Guyader
Agree
Fri 24 Jul 2015

It brings much more control over the reshare!

E

Elm
Agree
Fri 24 Jul 2015

M

Milan*
Agree
Sat 25 Jul 2015

DU

[deactivated account]
Agree
Sun 26 Jul 2015

SVB

Steffen van Bergerem
Block
Thu 30 Jul 2015

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

R

Ravenbird
Agree
Thu 30 Jul 2015

S

SuperTux88
Block
Fri 31 Jul 2015

Steffen++

S

StefOfficiel
Agree
Sat 1 Aug 2015

Y

yogrt
Agree
Fri 7 Aug 2015

DU

[deactivated account]
Agree
Fri 7 Aug 2015

X

Xophael
Agree
Fri 7 Aug 2015

G

Globulle Fri 24 Jul 2015

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

A

Augier Fri 24 Jul 2015

I like the wording ! :D

G

Globulle Fri 24 Jul 2015

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

G

Globulle Fri 24 Jul 2015

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.

E

EsΠ Fri 24 Jul 2015

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

E

EsΠ Fri 24 Jul 2015

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.

G

Globulle Fri 24 Jul 2015

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

A

Augier Sat 25 Jul 2015

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.

G

Globulle Sat 25 Jul 2015

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.

SVB

Steffen van Bergerem Sat 25 Jul 2015

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?
SVB

Steffen van Bergerem Sat 25 Jul 2015

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.

G

Globulle Sat 25 Jul 2015

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.

G

Globulle Sat 25 Jul 2015

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

SVB

Steffen van Bergerem Sat 25 Jul 2015

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?

G

Globulle Sat 25 Jul 2015

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.

SVB

Steffen van Bergerem Sat 25 Jul 2015

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.

G

Globulle Sat 25 Jul 2015

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?

S

SuperTux88 Sat 25 Jul 2015

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

SVB

Steffen van Bergerem Sat 25 Jul 2015

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.

G

Globulle Sat 25 Jul 2015

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

G

Globulle Sat 25 Jul 2015

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

SVB

Steffen van Bergerem Sat 25 Jul 2015

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

Globulle Sat 25 Jul 2015

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?

G

Globulle Sat 25 Jul 2015

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?

G

Globulle Thu 30 Jul 2015

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

SVB

Steffen van Bergerem Thu 30 Jul 2015

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

E

EsΠ Thu 30 Jul 2015

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.

G

Globulle Thu 30 Jul 2015

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

A

Augier Fri 31 Jul 2015

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 ?

SVB

Steffen van Bergerem Fri 31 Jul 2015

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.

A

Augier Fri 31 Jul 2015

You are probably right.

R

Ravenbird Fri 7 Aug 2015

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.

A

Augier Tue 11 Aug 2015

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.

RH

Roland Haeder Sun 16 Aug 2015

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