Read CONTEXT at end of post
Currently Voat’s "Private" subverse feature is primarily used to allow subs to disassociate their posts from v/all, all content is still public in every sense other than this. This isn’t really private, it’s more like a hidden setting.
For internal reasons Voat needs to implement a private subverse feature in which only approved people have access to the subverse content (pro tip: a lot of features we work on and end up offering were/are primarily developed for internal reasons like the upcoming Vote and Packages features).
Before we start any work on this feature, I want to discuss how to develop this feature and get your feedback and concerns.
As I see it, we have the classic concept of Private in which only approved people (members) can access subverse content. The only question is one of implementation: what controls access to subverse: subscriptions or moderator privileges? If we use subscriptions, we will have to modify the process so that moderators can approve a subscription request, otherwise the moderator feature would suffice. If we use a moderator approach, other users can see who is part of the private subverse which is good for transparency. Pros/cons to both approaches.
Some concerns I see:
-
Should we have different "Private" settings like a ReadOnly
differentiation so that a subverse can choose to display content to non-members but not allow non-members to submit posts/comments i.e. a read only approach?
-
What if a subverse is private and a new subscriber is added, should this new member have full access to subverse content or should all content submitted before they were added be inaccessible to them? In other words, only content submitted after a user became a member is visible to them. This concern is to allow existing members to be reassured their prior content is protected.
-
Should private subverse content show up in front-page/sets or should the subverse content only be accessible via navigating to the subverse itself?
-
Should pings be dropped when the target user isn’t a member?
There are probably other considerations I haven’t thought about, so let me know your thoughts.
CONTEXT
As with any change, we are all looking at the potential for abuse (which I see), so I want to give everyone a context of where this comes from so you can see the intentions involved with the thought.
I want to setup a corporate Voat instance for business related concerns that will be accessible by all Voat employees and members of the community that are involved with the operations of Voat (this is called dogfooding in the software world). In this instance I'd like to have a subverse about Finances that is restricted to only company executives, as well as a Legal subverse accessible to legal council, etc.
In these scenarios, private subverses are needed as a Voat developer or community manager wouldn't need access to this "sensitive" content.
I think it's important to note where this idea stems from and that this idea was never one of ill intention (i.e. This is the end of Voat!). This is why I mentioned "internal" above.
As always, we are just getting feedback here, let's try to look for solutions to the concerns rather than throwing out the baby with the bath water.
Edit
Consensus is in: Voat loves this idea... Pause... Pause... Not. ;)
view the rest of the comments →
SIayfire122 ago
So it seems you want an "Admin Only" subverse, which should only be accessible to you and people you give access to.
Here's what I think you should do.
Also, you could go about it a couple ways. You could have admin.voat.co/v/finance, or you could have voat.co/admin/finance.
whisky_cat ago
I'd say you have a good comment here. imo if Voat is truly open source, exposing the admin side itself is a risk (it'd potentially leak the URL signature on Github, and people would attack it).
I think the investor(s) or admins want a playground that's officially blocked to normal users. That's fine. No need to propagate that environment to the whole userbase. Again, unless users are asking for it, then it warrants user attention.
PuttItOut ago
We are developing many features that will be restricted on the site, like Votes. This would be a feature, if we implement it, that would have specific conditions relating to its use.
whisky_cat ago
Fair point that it's a feature with certain requirements. My point is if Voat's GitHub is up-to-date, it will document the code which shows access to "sensitive" content / private subs. And if it's for something like "business related concerns" you can bet people will try to crack it. FWIW I'm looking out for you here.
But to the other points being made, is there a non-admin case to have private sub(s)? I'm sure users would be curious if so. I think hiding stuff on Voat is kind of moot. Voat already gets the harshest forms of criticism and the most prolific Internet trolls and general hate-ists (don't get me wrong, I love to hate, too). So my opinion is you'd want to separate the concerns of business discussions from the actually software and database itself. Hope that helps explain what my sentiment is here, regardless of what's upcoming.