Add groups/lists of users and apps as fundamental API objects

[markwilcox]

Enable clients to create and manipulate groups of users and apps on the server side. There should be ACLs for read, write self (or own apps) and write others (others apps) permissions to the groups (which could in turn be either individuals or groups of users).

Set operations for manipulating these groups should be provided (intersection, union, difference, complement).

Why?

User groups:

• Could be used to implement followers/following - user can decide whether to make their follow lists public or not
• Can be used for mute lists (e.g. I might have a "noisy" group that I mute while I'm busy but switch on out of work hours), I think mute then becomes simply filtering by group
• Can be used to implement personal lists (as on Twitter)
• Can be used to implement "Views" or "Groupware lists" as described by A@teawithcarl on several ADN threads
• Allows users to collaborate on group creation
• Can be used to restrict post access as in #33 (although set operations replace whitelist/blacklist) for DM & group chat
• Enables developers to build group management controls and admin permissions for enterprise apps

App groups:

• Can be used as part of an implementation of filtering for protocols as discussed in #20 & #33
• Can be used in conjunction with #33 to implement user permissions (see below)
• Can be used in conjunction with user groups and #33 to implement sub-networks (possibly with different pricing tiers)
• Enable the creation of 3rd party app discovery tools

An important (although hopefully obvious) point on the interaction of groups and ACLs is that post visibility is determined dynamically, such that changes in membership of groups changes post visibility.

Having these groups as fundamental building blocks of the API makes them available from all clients, rather than have individual clients maintain their own groups in app data for each user.

Note on permissions - NOT the main point of this issue: There is an exceptionally long thread here: https://alpha.app.net/sean/post/63089 where the point is discussed that many users were attracted to the idea of a truly ad-free social network, while 3rd party developers might build apps that show ads next to their content. While it does not seem particularly feasible/desirable to enable users to opt-in to each app that is built individually, there could be a namespace for groups of apps that split them by user permissions. In this case there could be a permission "shows ads" - using ACLs as in #33 at post creation time, the user can then block their posts from appearing in all apps that display ads - this will cause some broken thread views in clients but only in the same way as having some users on mute. The ToS then just needs to enforce apps that display ads being added to the "shows ads" group by their creators. Alternately, a special opt-in group of users "anti-ad fundamentalists" :) could automatically have their posts blocked from all "shows ads" apps by the server, although this requires special treatment of permissions groups on the server side, it does allow people to change their stance on ads and have their historic posts show up. Similar special handling could be used around access to users' personal data (what limited amounts App.net holds).

[duncanwilcox]

I understand your motive here, I still don't understand why you don't crystallize the generic methods and possibilities into specifics.

For example the backend might have to go through hoops to implement intersections and unions in a generic way on the datastore, something that's orders of magnitude harder at scale, whereas knowing the specific use case, say "list of followers", makes everything simple.

What you are suggesting sounds like a theoretical ideal platform where social apps can be built on, in practice there's nothing wrong with App.net 1.0 implementing specific, more easily understood and optimized access policies.

[markwilcox]

What you are suggesting sounds like a theoretical ideal platform where social apps can be built on, in practice there's nothing wrong with App.net 1.0 implementing specific, more easily understood and optimized access policies.

Yes, I'm very deliberately suggesting a theoretical ideal platform for a huge range of social apps to be built on at this stage. Dalton said he wanted: a) People to be able to build other networks on their infrastructure b) It to be usable for the "Internet of Things"

I have a huge number of use cases I'd be interested in working on if this network reaches suitable scale for them. Awaiting some follow up from @berg on what is practically possible for them to build and scale, since he has the experience and is the one that's got to do it. I'd hope that generic set operations are not too tough since they're native in both Python & Redis stored sets (technologies used on the back end) and results can be cached in most cases.

None of this needs to be in App.net 1.0, just giving some input for the roadmap. If it's not scalable then we can start prioritising use cases. I'm somewhat philosophically opposed to designing optimised policies for specific cases we expect to be popular up front. I believe that's an instance of premature optimisation - unless there are obvious performance problems with the generic approach it ought to be possible to implement flexible mechanisms and optimise for the most popular uses actually observed as the system scales. That said, I have zero experience scaling systems to millions of users! :)

[markwilcox]

@CocoaNative Glad you agree we need lists of people. You seem to be looking almost exclusively at how you'd use them in a Twitter-like service. There have been several suggestions that ADN aspires to be much more than that. That said, I don't actually see much difference between what you've described in that concrete use case vs what I describe in a more abstract way.

Note: It's reasonable to expect set operations like union and intersection to be implemented by the client app.

I suggested that these operations be available on the server for the same reason I said this:

An important (although hopefully obvious) point on the interaction of groups and ACLs is that post visibility is determined dynamically, such that changes in membership of groups changes post visibility.

You don't want groups splintering all over the place and having to be managed by lots of people. An enterprise example (but you can invent more easily) if you want something to be visible to everyone in a certain organisation minus one department then you want to express that to the server as the difference between the groups. If a client app calculates the difference between the groups and creates a new group, that group will not be updated to reflect changes of membership of the original groups from which it was created, which is what you'd want to happen in many possible scenarios. A Twitter-like service example - say I want to see posts on iOS development at relatively low volume but high quality, I might try following the intersection of people followed by a few top devs. I'd still like my group to keep up with the times as new interesting voices are added and others move onto other platforms (surely not!) by benefitting from the ongoing follow list management by the original set of top devs.

Of course it doesn't make it useless if we don't have that feature but I think it's sufficiently useful to at least make a case for it being there and see if @berg and co can deliver it at scale.

[CocoaNative]

Edit: Apologies markwilcox. So much of your issue is fundamental to the feeds/channels I've been thinking about, and with "lists" in the title and discussed in the OP it looked like the appropriate place to mention them.

But to your actual issue: Yes, I would also like to see groups as fundamental API objects. These seem like absolute requirements to defining and managing server-based, user-created "channels" on app.net (essentially, very powerful expanded versions of "twitter-style lists").

Such groups could be used to specify who could post to each channel, who could see a channel's posts, and who could manage the channel (add/delete users).

As far as the union/intersection operations happening on the server, you bring up a good point about independent component groups changing underneath a group that is defined by them. So even though it may be extra work for team App.net, this sounds like the only way to go.

[shawndrape]

I see this hasn't been touched or categorized in a few months, but I hope the idea is still under consideration. An API for groups would allow devs to create customized streams of Posts for users which could be shared among applications.

In addition, as more non-client type applications are built on top of app.net there is a benefit to a user being able to specify a subset of their follower list for quick reference. You could even go as far as creating a separate OAuth scope for all followers and selected followers to allow users a choice.