Add support for groups in diaspora

Activitystrea.ms ist the webpage you're looking for. An activity is a small piece of XML or JSON, that consists of at least subject, verb and object. A casual posting is the triple of "Rasmus", "post" and "bla bla". But you could also deliver any activities like for example "Rasmus", "edit", "My Wikipage".

Just bringing this up again while support for groups is hampered by federation, I would propose a halfway house:

We implement groups, but restrict them to only users of a certain pod - and make it clear that this will be the case until future development makes federation possible.

I think this is important as a proof of concept and intent, and will also make diaspora potentially highly useful to a range of organisations and social movements - who could host their own pods and groups for decision making and communicating by members.

This would also be great for growing the diaspora network, as organisations are likely to have the resources to set up and maintain their own pods.

(This discussion is also related to this one here: https://www.loomio.org/discussions/1188)

@nickdowson By forking diaspora/diaspora, you (or someone else) can spike on this right now. There aren't many roadblocks when getting Diaspora to run off a different Git branch, so by all means...please do some experimentation and tell us what you find!

alas @tomscott , if only I could code!

@nickdowson That's an interesting thought; at the very least, we could have some basic code in place that could be improved upon later.

I think a good first step, though, is getting @florianstaudacher's Diaspora federation gem working with Diaspora. That could allow us to abstract away the working federation code in D*, making federated feature development much easier.

Actually, doing so could bring two very good benefits:

1. Allow for a modular federation abstraction. So, let's say we fork the existing Diaspora federation gem, and do one for Friendica Red's Zot2 schema, or we implement the Tent federation API. To some degree, we can make switching out gems easy, so that we can experiment with different protocol standards and see which ones suit our needs best.

2. With a level of abstraction, all of our existing federated features will make calls to equivalent code in the gem. So, swapping out federation gems would hopefully mean that features would have to only be adjusted very minimally.

I'm not keen on implementing a feature that would only be available to users within a pod and not cross-network. We need to be doing everything we can to enable and encourage inter-pod communication and mobility. Having a feature which only work intra-pod would mean that people who were connected would feel they need to be on the same pod as each other, which would lead to people wanting to migrate towards the huge pods, where all the people are, rather than away from them.

I appreciate your desire to have groups in Diaspora, Nick, but it can only be of use to individuals, and to the network as a whole, if some fundamental things are in place first. Let's focus attention on getting federation working properly, so that being on a single-user pod gives pretty much the same experience as being on a huge pod, and worry about features like this once the network architecture is ready for them.

@seantilleycommunit do you know where I can find that gem so I can help him? This has been something I've wanted to do for a long time and had no idea work was already underway.

@tomscott , there's a link on this thread: https://www.loomio.org/discussions/3704

Since groups need a special way of federation information to other pods, we couldn't program the federated groups unless we have put federation into an abstraction layer. It would be no good to make ourselves double work.

But a prototype could be nice. Pistos already did something like this prototype two years ago.

Let's keep this thing going! The last post was 1 year ago!? Why cease making Diaspora more awesome?