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.