Open danielsiders opened 10 years ago
I think that there should be a few more general groups built into the protocol, or at least ways to indicate them (honestly, I myself don't know what this entails right now), than the complete open-ended way it is set to be.
I can definitely see building set definitions into the protocol being a bad idea, with the same problem that projects with set post types for "everything" that a user could post about, which invariably leave something or some things out, but I think there need to be several wildcard-like approaches. Two examples: all people in the Tentiverse, and all people using a specific network/post-type (the latter may be moot with machine readable schemas).
(Bad) Imaginary use case for all-people-within-Tentiverse group: There should be some form of enticement on Tent. No matter what we think, it's a product, and we've got to sell it to people. We can't really do this on a massive level without somehow engaging people in the Tentiverse themselves. This might be a way to do that.
Another: I want to share with the Tentiverse. My post is on the Tentiverse (both in topic and location), and I want to share it only with others in the Tentiverse, in a sort-of intimate way (sounds really stupid, but I can't think of a better way to put it). This would allow me to do that.
Could the wildcard of all people within a specific network be provided by a group that the network provides for procurement to those within it that includes all entities using it? Can we share groups? A real-world example of this is Forrst, which allows you to make your posts public to the entire Internet, or local, available to all Forrst users. This is half of what I was getting at with the previous two "use cases".
Also, what about the use of groups as a sort of rolodex, not just for permissions. The group function might be able to provide additional usefulness on top of permissions--is there anything that needs to be built into the protocol to fully utilize the usefulness of groups?
@bnb The idea of "Tent-only posts" seems to surface occasionally and this seems like a good place and time to address it. There is no such thing as a Tent-only post (and there can't be). Public posts are public. To expose a post only to Tent users you would need to enumerate every user on Tent and establish relationships with each of them.
Hosted websites that offer "share only with the community" are walled gardens, Tent isn't, by design. What I think you're actually looking for is a way to hide from search engines. Restricting your content to users in a group is a great way to do that and eventually licenses will give you other (legal/contractual) options as well.
@danielsiders Let me preface this by saying I understand and accept what you said fully.
My idea with the Tent-only post was, as I sort-of communicated in the comment, to have a sort of wildcard that allows anybody who tries to access it from a tent server (e.g. looking at someone's status posts who you are not subscribed to on Cupcake) access to it.
I guess my question in regards to the "share only with the community" sites is: can this be done with Tent? Maybe it could be through sharing a group of all site members, hosted by an official site account, as a post available publicly or to a group (groupception). Sharing of groups like this is something I'd like to hear more on.
I know we're all pro-OSS, -openness, -freedom-of-information, but it's a reality we have to face that sites (not necessarily social ones) use this feature. I think it should be possible with Tent, even if it doesn't apply to Tent as a whole or Cupcake or whatever. I'm not accusing you of anything when I say this, but I think we're trying to apply an ideal model of openness on users, while saying we're good for almost anything.This is extremely limiting because it forces everyone to be "open" in the OSS-sense. If we really, really want mass adoption, we need to be completely open, as in up-for-anything, not forcibly open, as in everything is public and available and free (I know this isn't what Tent is, but I feel it's what you said about the walled gardens). The Internet succeeded because it is good for everything because of complete openness while not forcing openness on its users. If we really want to succeed, I think we need to do the same.
Sorry if that's obtuse or rude or dumb or rediculous. It's what makes sense to me, and I want to communicate it to you, so you can at least understand it, and maybe think about it.
@bnb The direct analogy here is "Can I make a web page that's only accessible to people with web browsers?". Tent is a set of APIs. Content is accessed through those APIs, so by definition if you're viewing Tent posts you're doing it through Tent. Web sites are accessible to the community of people who use web browsers, RSS is available to the community of people who use RSS readers, phone numbers can be dialed by people with phones and phone service. Tent content is available to the community of people who use Tent.
The finer print here is that in many cases people may access Tent posts through the public (nonauthenticated) HTTP API, which basically means they don't need an entity. That's the only theoretical place to put a "wall", but the reality is that anyone could make an app that created an entity whenever you wanted to view content on Tent.
The short answer is that the divide being described doesn't really exist technically within Tent-- not by virtue of open source politics, just technology. There are tons of ways of creating private enclaves of users/content (like groups) but there's really no other distinction. Users decide what's public, private, or limited to a select group of users. Hosting services could certainly create a group that effectively included all of their members, but there's no "all Tent users" category conceptually.
@danielsiders All right, thanks for the explanation.
Tent 0.4 will allow entities to create posts with permissions set to another entity's
group
.Background
Managing access control for collaboration in a distributed system is difficult. In the case of Tent it is easiest for a single user to manage the members of a group so that permissions can be kept in sync across a wide number of entities and posts.
For example in a group messaging app all users could set permissions on their posts to a
group
managed by the creator of the conversation. This would allow users to be added or removed trivially at a later point. (Participants would communicate with the owner of thegroup
to request the inclusion of a new participant.)Structure
Groups follow a similar model to tags. There is one
group
post and manygroup-member
posts.group-member
posts link to thegroup
post.Updates
When a user sets permission on one of her posts to another entity's
group
, her server automatically subscribes to allgroup-member
posts created by that entity which contain outbound links to thegroup
post.