New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Groups #299

Open
evanp opened this Issue Dec 20, 2012 · 12 comments

Comments

Projects
None yet
10 participants
@evanp
Contributor

evanp commented Dec 20, 2012

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

This comment has been minimized.

Show comment
Hide comment
@thedod

thedod Dec 20, 2012

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.

thedod commented Dec 20, 2012

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

This comment has been minimized.

Show comment
Hide comment
@evanp

evanp Dec 20, 2012

Contributor

There are lots of ways to do this, yes.

This is just a bookmark for doing it ever.

Contributor

evanp commented Dec 20, 2012

There are lots of ways to do this, yes.

This is just a bookmark for doing it ever.

@buttle

This comment has been minimized.

Show comment
Hide comment
@buttle

buttle Jan 9, 2013

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.

buttle commented Jan 9, 2013

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

This comment has been minimized.

Show comment
Hide comment
@stevank

stevank May 6, 2013

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

stevank commented May 6, 2013

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 comment has been minimized.

Show comment
Hide comment
@anarcat

anarcat Jul 15, 2013

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.

anarcat commented Jul 15, 2013

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

This comment has been minimized.

Show comment
Hide comment
@colegota

colegota Jul 29, 2013

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

colegota commented Jul 29, 2013

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

This comment has been minimized.

Show comment
Hide comment
@aurium

aurium Sep 15, 2013

My case is identical to that reported by Colegota.

We love groups!

aurium commented Sep 15, 2013

My case is identical to that reported by Colegota.

We love groups!

@marxistvegan

This comment has been minimized.

Show comment
Hide comment
@marxistvegan

marxistvegan Apr 26, 2014

@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

marxistvegan commented Apr 26, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@vasyugan

vasyugan Sep 1, 2014

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

vasyugan commented Sep 1, 2014

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

@salyavin

This comment has been minimized.

Show comment
Hide comment
@salyavin

salyavin Feb 3, 2015

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.

salyavin commented Feb 3, 2015

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

This comment has been minimized.

Show comment
Hide comment
@vasyugan

vasyugan Feb 3, 2015

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

vasyugan commented Feb 3, 2015

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

@evanp

This comment has been minimized.

Show comment
Hide comment
@evanp

evanp Feb 3, 2015

Contributor

Ping!

Contributor

evanp commented Feb 3, 2015

Ping!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment