In addition to the current “Public” and specific aspects permissions, can you please add a “Local” permission for posts that are public, but only for the local pod?
I’m helping several Yahoo and facebook groups who are looking for new hosts with better privacy abilities, and a diaspora* pod with the ability to restrict posts to local users would be an effective solution for them.
Thanks,
-robin
I am not sure if this is a good idea as Diaspora (and not just Diaspora) seems to be intended an open distributed network with as little centralization as possible. Pod is just a technical point of entry similar to e-mail server. Users are not supposed to think of pods (except remembering where they login) 
If you want to restrict others from participating in community then this is what aspects are for. If you want to just group certain community posts together then consider using a community tag. These solutions are not foolproof but they work.
If you want more Facebook’ish experience then you might want to check out other networks such is Friendica and Hubzilla. These have much more extensive privacy options, forum and event systems. Friendica also has more conventional look and feel, Hubzilla is somewhat complicated but has a lot of features built-in and basically can replace personal/community cloud (similar to Nextcloud) which can be handy for certain communities. I don’t think they have exactly what you are asking for though but offer more features in this direction (e.g. local public feed or ability to create standalone server). I am not saying these other networks are better but they are different and might suit you better. Diaspora has its unique advantages too.
Email servers also offer local-only features. (At least, the ones I’m used to running do.)
The idea here isn’t to restrict community, but to support sub-communities that want to guarantee the privacy of some their communication by seeing that sensitive material stays local to a server they control while also enabling them to communicate with the larger diaspora* community.
To give an example, one of the groups I’m helping is an alumni association who would like to move from a Facebook group for various (but mostly privacy) reasons. diaspora* would be a good solution for them with the addition of this feature (or something like it), since it’d give them a private space within a larger interconnected community.
I see you already found GitHub issue and commented on it
Anyway this groups issue is big and Iong standing so I wouldn’t expect it to be implemented anytime soon or in predictable timeframe (although it is possible). Since you have practical task at hand I gave suggestion to either try to make existing tools work or look at solutions with more suitable existing feature set.
Hah; yes. 
That one is definitely a longer term prospect, but I think the Groups implementation I described there would go a very long way towards making diaspora* a drop-in replacement for facebook in most users’ experiences.
The GitHub issue that most resembles this suggestion is https://github.com/diaspora/diaspora/issues/6767 though.
That one is much simpler than Groups and (as I commented there) pretty much what I suggested here before I looked through the GitHub issues list and found it; this does’t really overlap with Groups and should be a much quicker implementation.
Thinking more about this, it would also be useful to have a mid-level between Public and Local that would federate a post to a group of pods designated by the podmin as Neighbors.
This would help with the pod scaling problem by letting a growing pod shard off new pods but keep them inside a semi-private community layer.
My interest in this (and the groups feature) is to give podmins and users the flexibility to organize their communities however they like; without a flexible toolset, users are forced into a narrow set of interaction styles dictated by the technology choices made by the developers rather than being free to choose how to interact themselves.
Yes, and that’s a very specific use-case, which is very confusing to a lot of people. Most people expect email to work the way it’s advertised to work: you can send emails from your address to everyone with an email address. I’ve personally experienced this multiple times, where people with a company-internal email address tried to send me messages, and they did not understand why the mails never reached me. While I agree that there are valid use-cases for an inside-only-network, it’s horrible UX if built on the same system that also can do federation, and usually does federation.
Technically, yes. Practically, no. I feel like most of the arguments here are the same that were raised when talking about adding a “disable federation” setting for pods, which has been discussed many times already, and we generally agreed on it being a idea we don’t want to pursue.
Posting to diaspora* is already very confusing for everyone who’s not a technically versed person, and the whole concept of sharing with aspects or sharing something “public” confuses a lot of people. The implications that come with each choice (for example, that you can’t reshare non-public posts, and that search engines can and will index public posts) are already confusing a lot of folks. We’re doing a lousy job on explaining and offering meaningful choices.
Adding a “kinda public, but not federated” option is not an option if we care about less experienced users, which this project explicitly does. Even having the option exposed as a checkbox or whatever will confuse users, and there is no way we can explain that in a way everyone could understand.
There has been some research done on federated/decentralized systems in general, and one of the important reasons behind why people don’t use these systems is because they are confusing as heck. People don’t want to care about the whole federation thing; they expect it to work. They expect their content to show up where they expect it to be, and while they want to be in control over who sees their contents, they are interested in limiting the people with access to their content, not the machines who have access to the content.
A “local only” option would, without doubt, trick a lot of people with a shallow understanding of the feature’s design into using it for “well, this is a private post, I don’t want that everywhere in the internet”, and then wondering why their good friend has no access to that, just because they’re on a different server. In a perfect world, user’s of diaspora* should not have to think about the whole concept of pods when sharing content, but should only really care about people. Offering a “local only” option directly contradicts this principle.
You mentioned that having a “local only” model would enable diaspora* to be more useful for certain aspects, and while you are correct, I don’t think that’s important. diaspora* does not try to be a framework for everyone to build their own social thingy, diaspora* wants to build a social network. One social network. Just one that just so happens to be distributed over many servers.
But that’s just my opinion.
Here’s where I think I’m not connecting well as a n00b here with some of the longer-term participants:
diaspora* does not try to be a framework for everyone to build their own social thingy, diaspora* wants to build a social network. One social network.
I’m actually supporting that goal with this suggestion; the disconnect is that I see the view you’re espousing as actually insisting that diaspora* can only be one community, whereas I’m arguing that it can be one network with many communities in it.
I also think you’re wrong in thinking that people would be confused and don’t want to think about the pod layer: people are used to thinking in these terms (town->county->state->nation); they understand locality intuitively as long as its signposted well.
Which is actually why I’m suggesting that this has to be done as stream entries in the left nav bar, rather than merged into the existing “Public activity” stream. That would be hella confusing.
Also just my opinion.
That argument only works if you want to say pod == community. I don’t think that’s the case, and communities might or might not spread over multiple pods, and one pod might hold multiple communities. That’s where groups come into play, which should be a much nicer way of splitting of a part of the network, without actually… splitting apart the network.
You just have to trust me on that one, but I’ve been supporting diaspora* users with all levels of knowledge for over 9 years now. We’ve tried many different approaches, many different ways to onboard users, many different ways to explain the concept of “pods” and “the federation”, and while technically people almost always get it, everyone else does not. They don’t see the internet and communication on the internet as a “locality”-based thing, they see it as… the internet. A network where everyone on the globe is connected with each other. And I think that’s actually a fairly healthy way to see things.
(Sorry for the double-post and resulting notification spam, but this is too important to just be an edit)
Just to make the first point more clear: Let’s imagine your local hackerspace. Your local hackerspace is, without a doubt, a community. As a hackerspace, they want to run their own pod, so they do. They decide to share the weekly-rotating door pin with their members on diaspora*, and since that’s only relevant to members of the hackerspace, they want to share that information only within that community.
In your model, they could just check the “pls don’t federate this post” checkbox and be done with it. Since the pod does not allow for open sign ups, just members of the pod - and therefore members of the hackerspace - could see this information. Sounds good, right?
Well, no. Several members of that hackerspace are very concerned about online privacy, so they run their own pods. Given they expect their pod to be part of the whole diaspora* network, they also expect to be able to get the hackerspace information on their account. But in your model, they simply can’t. So they either have to accept that they’ll never get into the hackerspace again, or they have to get a second diaspora* account on the hackerspace-pod, just to view that information.
That’s already a mess, and it does not get less messy if you replace “hackerspace” with “local book club managed by people with no technical knowledge whatsoever”. It’s not hard to come up with may scenarios where a “local-only” mode completely violates everything people expect a federated social network to be.
What you are suggesting is a hack. All requirements solved by this hack can also be addressed by properly federating groups, which allow for “multiple communities within the network”, without violating principles of federated systems and without breaking expectations about how diaspora* works. Yes, groups are complex and will take a long time to implement properly, but implementing a hack just because it’s a nice quickfix for parts of the problem will only cause us grief and frustration. We’ve done that before. It wasn’t pleasant.
I’ll certainly grant you that from that perspective it’s a hack, and some uses of it would be very much better done with a full groups implementation (that would be the other feature request I added to the bounty of, by the way).
There are three reasons why, even if you view it as a hack, I think this is still worth it:
a) the level of effort and architectural implications are small and should not cause issues with any other part of the code; smaller effort and smaller impact outside the one feature means (to me) that the bar for inclusion should be relatively low
b) groups do not currently exist in diaspora*, and are unlikely to in the near future: that’s been a feature request for a long time and (to absolutely not minimize anyones effort on this) the GitHub conversation does not make me think that group functionality is likely to be available in the next few years
c) even when group functionality is available, it will not cover one of the reasons I want this: being able to participate in the larger diaspora* network while also guaranteeing that my users have some way to ensure that some posts are genuinely private by keeping them from being federated, so while this does overlap with groups in some ways, it’s still a feature I’ll want even after groups are available (that, I suppose, depends on exactly how groups are implemented actually)
Implementing it as an option, say in the diaspora.yml, would keep it from confusing anyone on a pod that doesn’t enable it. I respect your experience about this being confusing for users, though it goes against my instinct for whether that should be the case, but I know for a fact that some of my incoming users specifically want this.
Would you be open to accepting the feature if:
a) it defaults to disabled and must be enabled in the yml file
b) its impact is limited to entries in the share pulldown menu and the streams list?
This is by no means a criticism of anyone’s work or ethic; I do realize that this is basically me wanting to use the system in a way you haven’t wanted it to in the past.
Well, I’d say communities should be able to be one or more pods; yeah.
A strong groups implementation would be necessary for a community to be composed of just parts of one or more pods.
Having the pod be the basis of a community means that community can have a greater certainty of the privacy of their group communications, since a pod with closed registrations and some way of restricting some group posts to just that pod means they can be certain of that privacy.
I just think the network should to provide the tools for users to organize themselves however they choose, rather than specifying forms of organization.
From the fact that the GitHub feature request was tagged as undecided and needing discussion, I assume that the core devs are open to the feature existing, even if you don’t want to commit your own effort to making it happen.
I’m really not trying to be the arrogant n00b here, honest.
The “Neighborhood” part of this suggestion actually addresses this case specifically.
I’m thinking of neighborhood as “remote pods where I know and personally trust the podmin not to be all hinky”, so the hackerspace would presumably be willing to add the private pods of its members into their neighborhood list?
To be honest, though, a better implementation of this use case would be to use a diaspora* aspect and just not add any contacts to that aspect unless they’re on pods where you already trust the podmin to not be snooping posts.
I want to expand on this and be completely explicit:
A groups implementation like I described at https://github.com/diaspora/diaspora/issues/6278#issuecomment-552772759 but maybe with the addition of an “every new user on the pod auto-joins this group” option similar to what you can do for auto-connecting to a user now would totally replace this request; it would probably never have occurred to me to suggest this if that groups implementation existed.
It doesn’t, though, and probably won’t in the near-to-intermediate future so I think it’s worth putting in a feature like this now (now-ish; there’s no way I could learn enough to get it done that quickly) to get this part of the functionality while the much better solution is being created.
It’s relatively low effort if you’re expert with the codebase (and probably achievable even for someone like me with little Ruby and no diaspora* experience) and would not interfere with the implementation of the long-term goal.
And if it’s added as a default-off config file option, the podmin would have to explicitly choose it and could be warned in the explanatory text that it could confuse users about the distribution scope of some posts.
If it’s acceptable on those terms, then it’d be worth me digging through the code to see if I could do it myself or posting a higher bounty to try to lure a more experienced dev in.
The “Neighborhood” part of this suggestion actually addresses this case specifically. I’m thinking of neighborhood as “remote pods where I know and personally trust the podmin not to be all hinky”
While I know some people who would like something like this, I am also sure it will be confusing as hell for general public. Normal people don’t get federation. Many aren’t even really aware of other pods existing and UI/UX of Diaspora doesn’t differentiate between pods either.
Personally I see quite a lot of things to be addressed here:
While all of this can be resolved of course, it doesn’t look much easier to me than implementing group system. But definitely more confusing for users. Implementing this in crude minimalist form will be a hack indeed and suit very limited scope of users.
I agree that a “crude minimalist form” would be less than ideal, to put it lightly, and that the neighborhood idea is not fully fleshed out.
What I said earlier about not being an isolated feature and having any code-level implications for federation may not actually be true for the neighborhoods part (as you pointed out), for example.
I can answer some of your issues, at least:
From my looking at the code last night: reshareability appears to be determined by whether the public flag is set, which it would not be, so neighborhood pods would not allow reshare.
Since everything is push-based, it would be most consistent to be one-side.
Probably the same thing that happens to a post when you remove someone from an aspect: i.e. nothing?
You’re likely correct that this would suit a very limited scope of current users, but it’s important to enough of the people I talk to who I want to help move away from facebook for me to put the effort/money into getting something like this.
I expect to have the local-stream part running on my testing pod this week, unless my schedule gets taken up with something else. The post portion of the UI is in, though currently failing to post because local isn’t a recognized aspect so I still have to figure that part out.
OK, the local-activity stream is working on my test pod at https://eyepod.oksocial.net now. It’s not integrated to the mobile side, but I’ll try to do that this afternoon.
That’s an open-registration pod, so if you’re interested in or concerned about how this would look then please check it out for yourself.
As I said above, I’m by no means a Ruby dev (or JavaScript dev, which it turns out is necessary) but I can edit both languages even though I wouldn’t try to do anything in either from scratch. I’m also not much a git user either.
But if this is acceptable, I’ll try to figure out how to collect the changes into a pull request on GitHub.
I disagree. Just because something is done easily does not mean it’s a good idea to do. Implementing something just because it’s quick does ignore the future, and I don’t like ignoring the future. Imagine we’d go ahead and do as you suggest. What happens when we have groups? Now, we have two features that kinda do the same, but one is broken and the other one is working. However, we will never be able to fully remove the old implementation, as we’d need to keep the “local-only” stream view forever, or otherwise contents will be inaccessible. There is also no way for us to take “local-only” posts and magically move them into a group. You’re suggestion is a good way to create a lot of mess that we’ll never be able to clean up.
That makes it even worse. We already have a very hard time explaining the process of choosing a pod to non-technical users, and right now, it only kinda works because all pods are basically the same. There are some exceptions, like the availability of share services (as podmins have to manually set that up), and that is already confusing way too many people. Suddenly having pods where you can share thing in a different way that’s not available on all pods is not an improvement to this idea which will already, at its bare minimum, confuse a lot of people.
I’ll be honest and say that I will not merge this PR. I have explained why I think this is a bad idea in this thread, and I won’t repeat myself. However, I’m luckily not the only one with merge access, and maybe your idea is convincing to another team member. Also, diaspora* is free and open source software, so you’re absolutely fine running your own customized pod and redistribute the changes. If it turns out this feature is actually widely used and loved, I might reconsider my opinion.
Yeah, fair enough.
I disagree with you on the utility and possible confusion of it, but I need the feature for how I want to use diaspora* and that certainly doesn’t obligate you to do anything about it.
I’ll post a note on the GitHub then drop it if none of the other core devs think it’s acceptable.
Thanks, though; I do appreciate the honest disagreement without rancor.
I don’t particularly feel that a ‘local posting’ option is something needed in diaspora*; one of diaspora*'s core principles – and, in my view, strengths – is that people don’t need to be registered on the same server in order to interact. However, would this be an option that would work technically within diaspora*'s current functioning?
Have the option for a pod to set an ‘auto-share’ for every new account on that pod that auto-shares with every existing account on that pod, and set the existing accounts to automatically share back. Obviously each account would need the ability to opt out of this, but for a pod set up specifically for a community, this would enable users to share with that whole pod without manually having to add everyone to an aspect. @denschub anything here that might be workable?
I don’t see the need for ‘local’ pods because d*'s fundamental nature is federated, and part of the reason for that is that it gives every member choice and control – there is no need for them to be registered on any particular pod in order to participate in any community. No one should be forced to register with any particular pod if they would be more comfortable registered with another one. It’s possible that there is a dispute between the person who sets up a pod for a community and another member of that community, and it would be wrong if that second person had to entrust all their personal details to the admin, with whom they have a dispute (there could even have been online stalking). It’s right that the person can find another pod whose admin they are more happy to entrust with this information – or, if they want full privacy and control – to set up their own pod. They should then be able to interact with all the members of their online community just as if they all shared the same server space.
The way diaspora* provides to interact with a particular community is to use aspects and tags. If you want to form a community here, share details and add each other to aspects, then you can each post to that aspect and everyone in the ‘group’ will be able to see it. It’s not ideal, but it can be done. One caveat; for privacy reasons, only the people included in an aspect at the time of posting will ever be able to see a post. There’s no way around that.