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).
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.
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.
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?
How can you spread privately when all likes and comments from your private spread go to the public original 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âŚ
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 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.
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.
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. 
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.
- 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).
- 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.
Abstract
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.
Naming
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.
Idea
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://denschub@pod.geraspora.de/post/14127090719d01351b19101b0e8ace24 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?
2 Likes