Groups

[evanp]

We need to support groups. I think a group should just repeat objects that are posted to it, bcc all group members. Is there more to it than that?

[thedod]

There are lots of "policy features" we can [should?] implement: admin should authorize joins, members can invite, moderators should authorize each post, etc.

[not necessarily good] Ideas about implementation:

IMHO, best is not to do these things hard-wired, but rather have

1. additional intermediate states (e.g. "wants to join but needs admin moderation", "invited, but hasn't confirmed invitation")
2. "policy bot" actors (maybe even external services) with fine-grained permissions

Group admins can grant a bot rights to change user<->group or post<->group relations (not excessive rights - or it would become a vulnerability). Bots should also be able to send messages to admins/moderators (or all members - depending on the policy the bot is implementing). Such a message will be relayed via the group (because that's what the members are subscribed to), and there should be a mechanism that relays replies to the bot.

Examples

1. Bot sends a message to all group members "thedod wants to join, I need at least 3 members to reply with yes".
2. Bot posts to moderators "here's a link to a post that needs moderation, please reply with yes or no" (in this case, bot doesn't need to have rights to message all members - only moderators).

The "respond with yes or no" can also be presented as GUI yes/no buttons (using post object-properties that can be understood by smart enough clients), but this is a bit off-topic here.

[evanp]

There are lots of ways to do this, yes.

This is just a bookmark for doing it ever.

[buttle]

There should be a way to view all posts to a group together, in one place, like SN. If not, the Bcc's would get lost in the stream. (this is an important feature for us). thnx.

[stevank]

I think Groups should have profiles with "favorites", just like users. Group admin could use favorites to bookmark content important for specific group.

[anarcat]

This is a major drawback since the migration. We were using the "koumbitstatus" group to do status updates for our network in a decentralised way, on some servers outside of our main infrastructure. This functionality is now completely gone.

While I think now that we shouldn't have relied on identi.ca for that service, I was expecting the "federation" bit to survive the migration: I post those notices from my home statusnet server, and the fact that those don't communicate at all anymore makes this a very difficult migration. This will clearly make us hesitant in using pump.io or any other federated protocol (as opposed to say: a simple html page with rss feeds) to post our updates.

[colegota]

Hi!

I know that you have a lot of work to do, but I think groups make the difference between useful or not. We are not interested only in follow people but also in follow themes, ideas, movements... Since migration to pump.io my timeline it's no such interesting as before.

Please, make an effort to give back groups!

Thanks, Colegota

[aurium]

My case is identical to that reported by Colegota.

We love groups!

[marxistvegan]

@evanp I would be interested in testing groups out and possibly expanding their abilities. I know baby steps, but the long term thought I have is for group abilities to have an agenda structure of the statusnet/gnusocial with polls, questions, events etc

[vasyugan]

Sadly, another reason, why identi.ca has been virtually dead since the move to pump.io.. Groups are a must.

[salyavin]

I agree with vasygan. Groups are a must. Groups make it easier to have conversations with those you do not follow about a particular topic. It is one of th things that made status.net great. Without it I would not expect pump.io to be used much.

[vasyugan]

I guess the broader problem is: Pump.io development is dead, no commit since 22 June 2014. R.I.P.

[evanp]

Ping!