Reshare old posts with (new) contacts

Hey, I’m new here and got my own pod running for me and my family, as I wanted a place to share private memories online. Currently I’m trying to convince them to join and explain the system one after another.

One problem is, that as there are no public posts their feeds are empty and they missed all the previous posts.

As the wiki states, posts are only shared with the aspects’ members at time of writing, new contacts can’t see old posts. Related github issues are 6596 and 5905.

As jhass states there the current design is to avoid accidental leak of data. I like that and don’t want to change it, but I’d like the abillity to activly make posts visible to more people later on without having to repost it. And regarding this I’m not alone.

As far as I understand the database layout, once a post is submitted it’s visibillity is determined on a per-user basis, the aspects it was posted to are not stored. Thus it should be easy to make a single post visible for a new contact, while it’s impossible to select all posts by aspect.

So to make it easier to select and reshare old posts some kind of activity log, perhaps with tag-filter would be great (select all #tag posts and share with contact xy).

It should be possible to federate old posts to remote pods when granting access, to, or?

Another idea that goes hand in hand is that I want to share a post with specific persons only, not whole aspects. (Currently I would have to create a new aspect per post/person I want to share to to achieve this, that’s not intuitive)

So to sum it up:

  • Select persons as well as aspects while writing posts
  • Make posts visible to more persons/aspects later
  • Have a filterable activity/post log

Please not that I’m not trying to revoke access to posts, just granting it to even more users.


Note: This discussion was imported from Loomio. Click here to view the original discussion.

3 Likes

Hi, I totally agree with you and have the same problem with new familly members or friends joining up…

3 Likes

I propose we add a pop up each time the user adds a new contact asking whether they wanted to fire off previous limited posts in that aspect to the new contact with the default option (on the right side) as “no”. For starters, we can just conservatively place the posts where they belong in terms of date, and thus these posts would probably be buried in the stream for people who have heavy streams. This will still help in the use case of sharing a link to an old limited post to a new contact without having to repost or resend through the rails console.

“As jhass states there the current design is to avoid accidental leak of data.”

jhass would you be able to expand on this? I’m wondering if you’re thinking of the case where you accidentally add a contact to an different aspect than you intended and before you can remove the contact from the aspect, the pod fires off the limited posts the contact was not supposed to receive. I believe the pop up would mitigate this issue.

2 Likes

So when I add a contact and assign one or more aspects to it, he/she will only see my postings from then onwards and not any older post? This is quite not logic in my opinion.

So, why exactly is this so in diaspora? I don’t really understand the leakage of data argument. Is that not already guarded by the fact of assigning aspects to contacts?

That is probably the main issue that prevents me from using it as a facebook replacement, although I am in desperate search for one. And diaspora looks soooooo promising!

1 Like

“So, why exactly is this so in diaspora? I don’t really understand the leakage of data argument. Is that not already guarded by the fact of assigning aspects to contacts?”

The data leakage is more time related. I do not remember what kind of crazy stuff I thought was funny five years ago and probably do not want to share it with new contacts. The idea is, that a post’s visibility is decided at time of writing.

Also after writing a post, in the database is only stored which user can see which post. There is no information to which aspect a post was submitted initially.

1 Like

Thanks for this info!

At least, I think, I should be given an option to whether I want my new contact to see all history or not. Because in most cases at would be yes. Somehow I assume that is what many user would expect, too.

Since you mention the technical difficulty, I believe that this is a big issue. An obvious solution would be to associate posts with aspects rather than people, but to implement this now is probably a drastic change.

I hope it was the right way to dig up this thread to continue the discussion about that topic. Correct me if I’m wrong.

I would also like to have a feature, which enables me to reshare older posts to new contacts.

Ideally, I would like to be able to get the following option at the time I’m adding new users to a certain aspect. A list of all posts I’ve posted to that aspect, so that I can choose from which time on I would like to share the content to the newly added user.

I see the challenge with the current data structure (posts are shared to contacts instead of aspects and the aspect is not recorded) and therefore also think, that it’s the best approach to reshare posts by tags. I imagine a similar “reshare from that time on” menu with all the post titles and their publishing date and think that it would be simpler if to add that “reshare posts to” button to individual contacts instead of aspects.
I can imagine another option, where you can go to a certain aspect and add or remove a certain member, to or from all posts with the corresponding aspect ID, if the aspect ID would also be stored in the posts database table in addition to the users, which can see the post.

3 Likes

Considering that the (arguably) biggest problem that Diaspora* has is its small user base, I think this feature is quite important. Currently, new users can see no content at all from their friends, which creates the impression that diaspora* is abandoned. The issues that @knutmithut mentioned are closed at the moment, 5252 is the open, unassigned issue that currently addresses this (as far as I could find).

3 Likes

Can someone on core team speak to whether this is within the realm of reasonable possibility such that it is worth putting a bounty on it?

I would like to rewrite 5252 to be more a more clear and succinct feature request for an option to do this, and put a bounty on it. Without this feature, diaspora is pretty useless to me for what I mostly want it for, which is sharing pictures of my children with relatives (who will want to see all the pictures, not just the ones posted after they sign up).

However, I don’t want to put up money for (and possibly entice other people to put up money for) something that the core team is dead set against, or believes is practically impossible. I see a lot of core team comments in other places like “that’s intended behavior”, “this is by design”, and “makes the federation protocol a lot easier”. If that’s set in stone, then diaspora just isn’t the software for me, and I’ll move on.

2 Likes

It’s very unlikely that this will change, because it’s the base of how diaspora works. You decide on which people you share something at the moment when you share something, and it’s sent to these people. You can’t remove somebody from this list after you shared it and you can’t add somebody (well, in theory you could, but I come back later to that). Diaspora isn’t a wiki where you can manage permissions with groups and give a group permissions to view a section and then just add somebody to a group. It’s also not something like nextcloud/dropbox/whatever where you can create an album with photos and then send somebody the link and then can just send the same link to more people. When you need something like this, then diaspora probably isn’t the right tool for you.

You need to add your family first and then you can share the photos with them. When they don’t want to register then they don’t see the photos. You can see it like in real life when you tell them to come over to watch the photos, and when they don’t come, then they don’t see the photos. When you show more photos the next day and they come over this time, then they see the new photos, but not the photos from yesterday.

Now back to sending an existing post to new people. In theory this is possibly (with the protocol), but sending all your past posts to new contacts would add a lot of load to the network and to smaller pods, because it’s not built for that case. And maybe not everybody is happy with sharing old stuff with new people (when you have a photo with some people, and they agreed that you share it with a group of people, they maybe don’t agree with sharing that old image with new members of the group).

Because of these reasons/problems it’s very unlikely that this will change.

Tragic. Ok, back to user-access-controlled WordPress for kid pics, then. FWIW, I think this missing feature is the difference between using Diaspora daily, and enticing all my relatives to it to use it (“if you want to see pictures of little Alice and Owen, they’re on Diaspora at [handle], you can sign up to use my pod at [URL]”), and not using it at all.

1 Like

Well, it would work when they start using it before you post the photos. But if they don’t want to use it now, I don’t think they would use it later after you posted all the photos. Anyway, when wordpress fits your need, then that’s OK.

@xenotropic I understand it might be the difference between using D* as you main source and not using it at all, and that’s a shame. But I think you might be in a minority of potential users.

Privacy and ownership of data are two of the basic philosophies of D*. And that applies to people who comment on limited posts as much as to people who post limited posts. You might only add to your limited aspects other family members as they sign up to D*, and all of your existing family contacts might be fine with that, but how to code a feature that allows you to do that but doesn’t allow other people to open up private conversations to people whom the earlier commenters would not be happy to be involved? I don’t see a way to do that. If you do, please describe it.

As in so many other ways, the problem is that if you want to be a part of a privacy-focused network you have to start thinking in a very different way from that which Facebook has conditioned us all to think. Privacy or convenience: which is the more important? Because you can’t always have both. As Benjamin says, you have to start thinking ahead about who you want to share what with. And if someone simply can’t join D* before you share some important, photo, you could always upload it again after they have joined.

For now this seems like it’s a losing battle, but for posterity, and just to give a different perspective and help you think about your project (or perhaps influence someone who creates a different project), I want to address some of these arguments. I say all of this out of love and respect: I wouldn’t be spending the time writing this if you hadn’t already made something which is really awesome.

Overall: privacy is important, but it is not the only Diaspora principle. It is a social network, so to a certain extent there has to be some accommodation of the types of how people actually function in social groups, which, being social, are not 100% private. So:

You need to add your family first and then you can share the photos with them.

This is not how actual humans in anyone’s family works. I can’t “add my family”, they have to choose to add themselves if they aren’t on Diaspora already. It is very hard to get my cousins and aunts to all sign up in advance for what is currently an empty screen that maybe next week we’ll have some cool pictures in it.

You can see it like in real life when you tell them to come over to watch the photos, and when they
don’t come, then they don’t see the photos. When you show more photos the next day and they come
over this time, then they see the new photos, but not the photos from yesterday.

A better real life analogy would be if you refuse to show your wedding album to anyone who you didn’t know at the time you got married. A lot of the purpose that we keep pictures is to tell people about the past experience that make us who we are today. What we do around campfires and at bars when we meet new people is to tell people about what we did in the past, perhaps earlier that day or last month, or whip out our phones and show them pictures of it. The prior set of posts is typically the social media equivalent of that.

sending all your past posts to new contacts would add a lot of load to the network and to smaller pods, because it’s not built for that case

I mean, Diaspora is built to exchange pictures and information between people who want to share it, and that’s what the podmins signed up for. If a person who sharing it elects to share with someone else, even if it’s a repost-to-new-contact, it’s sort of what the network and the pods are there for the first place, right? Do adapt what people want to the technology, or adapt the technology to what people want?

when you have a photo with some people, and they agreed that you share it with a group of people, they maybe don’t agree with sharing that old image with new members of the group

When you allow someone to share a photo or information with the group of people, it’s because you trust the person who’s doing the sharing. If you said that they can share a photo with their friends, then you trust them to share with new friends who are of the same type as their existing friends, and not that they’re going to become friends with 5000 people or all of their ex-girlfriends. Plus it’s not really private, when it has been shared, it can be copied-and-pasted outside the protocol. A social network is never going to be a fortress.

But if they don’t want to use it now, I don’t think they would use it later after you posted all the photos.

Again, this is not how I have observed humans to act in the wild. There’s a big difference between telling an aunt or a cousin or even an old friend from high school “hey there is this cool distributed social network that respect privacy and doesn’t have ads” and “hey there is this cool distributed social network that respects privacy and doesn’t have ads, and it already has a bunch of cute pictures of my daughter from the last few months”. It is the way people work (who are not computer programmers). The second one is much more enticing.

how to code a feature that allows you to do that but doesn’t allow other people to open up private conversations to people whom the earlier commenters would not be happy to be involved

First, I just want to point out that I don’t think that commenters currently would even know who their comments are being shared with, right? If you’re viewing a non-public post because someone has shared with you, all you see on the post is “Limited”, reflective of the asymmetrical nature of aspects. That asymmetry infers a kind of data ownership and control by the person who made the original post: they are the only one who knows who their non-public post was shared with. I wouldn’t make a lot of assumptions about privacy on a post where I don’t even know who my comments are visible to. I have to trust the originator of that post to manage it effectively.

Second, I think this gets back to my trust issue above, if I comment on someone else’s Limited post, I assume that’s part of their data, that I’ve essentially given it to them. If I don’t trust them with it, I wouldn’t be saying that to them. I don’t even know if they’ve shared it with their friends, their family, their acquaintances . . . why would it be bothered if it were shared with new people in those aspects?

Privacy or convenience: which is the more important?

Well, it’s a continuum not a binary. Privacy is one of the pillars of Diaspora , but it’s not the only one. Social-ness and control and freedom are also there. “Convenience” makes it sound trivial, but at a certain point things become so inconvenient that they are just not functional. Certainly if privacy trumped everything, and we trust no one, then a user wouldn’t be posting anything to anyone on the internet (or they would be post it anonymously), and only send emails to people with whom they had exchanged PGP keys IRL. But I would say we were dealing with here is not necessarily convenience, it’s basic functionality as to how people communicate and act in social groups. You have software that is for sharing thoughts and ideas with groups of people. And people want to use this kind of software to communicate their stories as timeline arcs – not just what happened today, but what happened last week, last month.

And if someone simply can’t join D* before you share some important, photo, you could always upload it again after they have joined.

“Hey, Aunt Sally just joined Diaspora, so sorry to the other 30 relatives and family, I have to post this picture again” (or, yeah, I could create an aspect just for Aunt Sally, and oh wait Uncle Jim just joined, another aspect for him . . .). Again, yes privacy is important, but it is one principle of several, and sociability and control are also Diaspora principles.

“But I think you might be in a minority of potential users.”

I’m not exactly alone here. This has been submitted as a github issue at least three separate times, and here we have at least a half dozen people showing up over the last year on this post in Discourse. To the extent that current Diaspora users are not all demanding this, I would assign that to survivorship bias: the kind of people who don’t mind not having this feature are the ones that stay on Diaspora. The kind of people who do mind this sort of thing try out Diaspora and are like “oh that doesn’t work they can’t see my old pictures” and they stop using it.

So, again, not expecting Diaspora core team to change its approach (another item I don’t have time to go into is that some of what is happening here is probably German vs American cultural differences on the balance of functionality vs privacy: differences unlikely to change no matter how much discourse, because they are based on different lived events), but I did want to put this all out there as food for thought and contemplation. The reason I care enough to spend my evening writing this is because I really do want to get my aunts and uncles and cousins and university friends off Facebook, to encourage means of online social communication that are decentralized, open-source, non-corporate, and non-capitalist. Diaspora seems so close. But if I can’t create a honeypot of “here’s cute kid pictures right now if you sign up” (for others it might be vacation pictures last month, or another person talked about a photographer who wanted people to be able to see his portfolio through time), I really don’t think I can do that, because that’s how those people behave. History and past shared experience is important for human social interactions. Maybe you are like “well my information is private, who cares about them,” but this kind of infrastructure changes the world we live in whether we use it or not (see: Analytica, Cambridge). What I want to see in the world, as a matter of general public interest, is open source social networking software that gives ordinary people a means to communicate socially in a way that mimics what they do in real life, minus the exploitation of ads, marketing, and all the rest of the corporate control. To me, worrying about whether a few more people might see my comments on someone’s post a year from now is a distant second place.

Thanks for reading.

Joe

4 Likes

Dear friends,
now it seems for me, this is the most important thread for my problems with diaspora. I explained it in the thread %aspect and group. I am new here so please, maybe you need more tolerance.

I found in this discussion some contradictions.

  • do we assign aspect to user or user to aspect?
  • do we assign post to user or to autor(user) and aspect?
    The real problems seems for me now, that the posts lost the aspect information.
  • do we send posts to user or do we every time decide, what the user see with the decision for a specific user view?

For me it looks that many people in this group don’t follow a general logic in the decision, what a user can see in his view. Normally, it would be never a propblem, if a new user use an existing aspect to see all the posts, that was written for this aspect. And the argumentation from @goob, that maybe he don’t like, what he have written some years before, is not a substantial argumentation. We can also use a positive view, because it is our history of evolution.

The argument, that a post is only viewable for that user, that was involved in the time of writing, is totally contraproductive to a living network with dynamical interconnections. And it is a hidden interpretation of the general philosophy od diaspora, what we can read in the documentation.

In this short time, i work with diaspora, beside of many realy good things, i am always confronted with a different logic interpratation. One of that is, that general the users can decide, who can see his posts. This is directly connected to the questions of @Joseph Morris.

For me, the posts are the central objects in Diaspora. The autors are users. And the autors assign a thematical attribute to his posts. With that he can control the viewer space. And the viewer space is dynamical. The attributes from the posts are statical.

But this, i know, stays in contradiction to the implementation, that the post lost the aspect attribute and changed it to a statical internal value.

All this, was i write, is based on my interpretation, that the posts are on the pod-server of the autor and all view definition create a specific extraction of posts from a big posts-pool. I am not sure, that this is correct in the concept of inter-connected pod-servers and inter-connected networks.

1 Like

Thanks to the folks bringing this topic up!

Actually this issue is the only thing which keeps me from setting up a pod for friends and family. My usecase is very similar to xenotropic’s: I want to share content with my friends and I do not want to use facebook. No one of my friends is at Diaspora right now, because there is no “reason” for them. If I would invite them into an empty page, no one would stay. It would be already hard getting them to register “yet another account” anyway. But having already content there would be a good enough “reason” to try. Furthermore friends come and go, so it’s impossible to statically set it up and then start posting. Live’s changing, everyday. :slight_smile:

When it comes to the point of accidental leak of data: Why not give the user a choice? It would be pretty fine for me, if this feature is turned off at default. If I turn it on in settings like “[x] make old posts available for new group-members”, there could be a big disclaimer like “WARNING: There is a potential leak of data!!! Please type: Yes, I know what I’m doing 20times”. :slight_smile:

@xenotropic: Please do not devide us into German/American-POV here. :wink: I’m German actually. Of course I live very privacy oriented, but because I WANT to, not because some software tells me. :slight_smile:

@deusfigendi: Unfortunately friendica also doesn’t seem to have that feature. I poked around with it the last two ours. Maybe it’s possible somehow, but I like D* way more from the usability POV. If anoyone can suggest some other project, please drop me a line where to look. https://write.as looks interesting, but is still not ready. :frowning:

I personally don’t consider anything I post to be important enough that people must be able to access it.

I’m in favor of addressing this issue in some way too. I understand the reasons why the system works the way it does but from a use case perspective the inability to do this on limited posts is something I still am not happy with. Ironically I end up posting a lot more Public than Limited posts here. I think there would be a way to do this that will address privacy concerns, DDoS effect concerns, et cetera but it’s something that would have to be considered. A manual “reshare” something along the lines of an “edit” functionality which is also being discussed could be interesting. If that could be done in a way that doesn’t change up the timeline that could also be interesting. There’s a lot between here and there though, of course.

2 Likes

There is no logic for having different aspects if only your older public posts can be viewed by new members.
I just wasted months setting up my own pod and finally convinced my wife to create an account and she can’t see our vacation pictures I posted unless I repost them.
It’s almost as if this app is designed for a pedophile network.

It limits communication though. Basically it means you can’t refer to existing content. For some use cases it doesn’t matter (meme posting, tweeting, etc), for more structured blogging it is real pain. I like Diaspora but it is the reason I use it for public posts only.

I get the privacy argument but I think it should be poster’s responsibility. In fact it is still their responsibility because if people really want they still can reshare their older limited posts complete with comments by taking a screenshot, copy-pasting them, whatever. So if this behavior is by design it doesn’t solve the problem, just adds some hindrance to both potentially problematic and legitimate actions. Same for not allowing to reshare limited posts.

The ideas about controlled pushing the aspect to new users seem solid to me. This philosophy works in some other products (Telegram chats, for example, allow you to add new members with or without access to previous chat history).

Also it would be nice if people could “proxy” public posts. E.g. if there is a public post for me and it includes links to other public posts in the body or comments then these are pushed to me too (if possible) so I can view them from my pod.

Update:

I gave it some thinking (and spent some time advertising Diaspora to some folks looking for Google Plus alternative) and came to conclusion public posts also need “push to new contacts” feature. Otherwise it limits decentralization aspect as not everyone shares the same pod and people do want to see past entries of their friends but it can be a challenge even with public posts - people don’t really get the technical concepts of federation, how pods talk, etc. They just click on profile and see it empty. Also not being able to easily access older content (references to which can come up in later interaction) leaves impression of being left out.

I am not sure how it should be done technically and if it is possible at all but it would be good to have an option to “share history” when adding someone (which means older posts will be pushed to them). Maybe it should happen to only limited number of posts (configurable by podmin?) and with the lowest priority to minimize server load.