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

Support groups #139

Open
cphuntington97 opened this Issue Nov 5, 2016 · 29 comments

Comments

Projects
None yet
@cphuntington97
Copy link

cphuntington97 commented Nov 5, 2016

support groups using bangtags

@Gargron

This comment has been minimized.

Copy link
Member

Gargron commented Nov 5, 2016

I made a decision not to implement groups. They offer little benefit over a cost of added complexity, and the bangtag syntax personally irks me too.

@Gargron Gargron added the wontfix label Nov 5, 2016

@Gargron Gargron closed this Nov 7, 2016

alpaca-tc added a commit to pixiv/mastodon that referenced this issue Apr 24, 2017

Squash commit logs
Revert "Revert "Create component for announcements""
Merge pull request tootsuite#161 from pixiv/revert-160-feature/create_component_for_announcements
Revert "Create component for announcements"
Merge pull request tootsuite#160 from pixiv/feature/create_component_for_announcements
typo
Change announcement manager
Remove unused import
remove comment out
Create react-component for announcements
Merge pull request tootsuite#156 from pixiv/revert-155-fix_autosuggest_z_index
Revert "トゥートの登録フォームで長文を書いても、アナウンスパネルにかぶらないように"
Merge pull request tootsuite#155 from pixiv/fix_autosuggest_z_index
(origin/fix_autosuggest_z_index, fix_autosuggest_z_index) Add zindex style
(svg_encode) Merge pull request tootsuite#141 from pixiv/add_privacy_policy_for_sp
Fix title/ogp.
Fix text.
Merge pull request tootsuite#151 from pixiv/add_protocol
(origin/add_protocol, add_protocol) Add protocol
Merge pull request tootsuite#149 from pixiv/allow_5_megabytes
(origin/allow_5_megabytes, allow_5_megabytes) Reject large profile
Merge pull request tootsuite#148 from pixiv/notice_pixiv_link
(origin/notice_pixiv_link, notice_pixiv_link) pixivアカウントと連携した場合の注意を表記する
Merge pull request tootsuite#147 from pixiv/disable_two_factor_authentication
(origin/disable_two_factor_authentication, disable_two_factor_authentication) Hide two factor authentication if user is linked with pixiv account
二段階認証が有効な場合はpixiv連携できない
Merge pull request tootsuite#145 from pixiv/remove_announcements
(origin/remove_announcements, remove_announcements) Remove announcements on mobile
Merge pull request tootsuite#144 from pixiv/fix_sidebar_ex
Fix sidebar scroll css.
Merge pull request tootsuite#143 from pixiv/fix_sidebar_scroll
Merge pull request tootsuite#122 from pixiv/render_announcements
Render announcements
Make sideber scrollabled at setting page.
Merge pull request tootsuite#139 from pixiv/replace_mastodon_to_pawoo
Add sample text at view.
Add controller method.
Add endpoint.
Destroy InitialPasswordUsage
Remove unnecessary index
Expire cache of nginx
(origin/replace_mastodon_to_pawoo, replace_mastodon_to_pawoo) Replace 'Mastodon' -> 'Pawoo'
Update site_title 'Mastodon' -> 'Pawoo'
Replace 'Mastodon' with 'Pawoo'
Render pixiv url
Prevent destroy if user has initial_password_usage
Replace factory.dev with pawoo.dev
Add comment for normalize_username
Render error message when failed linking
Optimize query for finding by uid and provider
Update locale of oauth_authentication
Rename RedisCache -> RedisSessionStore
Enable popup signup sdk
Do not remove upcase
Replace :preload -> :includes
Refactor Form::OauthRegistration
Find oauth_authentication by uid
(hotfix_oauth_login) Merge pull request tootsuite#135 from pixiv/replace_toppage_image
Remove site_extended_description
Replace demo image
Revert cookie_store key
Fix text.
Revert "Add i18n-tasks to ci"
cookie_storeのキー名を変更
Merge pull request tootsuite#105 from pixiv/omniauth-pixiv
Merge pull request tootsuite#124 from pixiv/improve_top_page
(origin/improve_top_page, improve_top_page) Skip view spec for contact page
Improve home#show home#more
Merge pull request tootsuite#123 from pixiv/i18n-tasks
(origin/i18n-tasks) Add i18n-tasks to ci
(origin/omniauth-pixiv, omniauth-pixiv) Fixes undefined method error
日本語とスタイルを調整
Merge pull request tootsuite#100 from pixiv/fix/remove-unused-message
Fixed typo
Merge pull request tootsuite#113 from pixiv/omniauth-pixiv-with-badge
Add oauth authentication status badge to user page
Add oauth authentication status badge
Load oauth_authentications
Rename `ソーシャルログイン` -> `pixivアカウント連携`
Update secrets.yml
Fixes gemfiles
Update oauth_registration.rb
Add null constraint to initial_password_usages
Fixes specs
Do not delete oauth_authentication if user has initial_password_usage
Send reset password instruction if user has initial password
Send reset password instruction if user has initial password
Create InitialPasswordUsage for initial user
Create InitialPasswordUsage
Destroy OauthAuthentication that related with expired users
Update oauth registration form
signin popup
Add omniauth action buttons
autoresize textarea
replace oops image
media aspect ratio change to 16:9
Create OauthRegistrationsController
CookieStore can not store data because it is tiny
Clean redis data each test
Create Auth::OmniauthCallbacksController
Create Settings::OauthAuthenticationsController
Create OauthAuthentication
Install omniauth-pixiv
Feature/change displayname style (tootsuite#102)
Merge pull request tootsuite#76 from pixiv/feature/hide-follow-when-blocked
Merge pull request tootsuite#103 from pixiv/fsubal/fix-broken-account-description
Merge pull request tootsuite#66 from pixiv/fix/url_escape
add HTML escape test
put a comma after the last item
ブロックしているユーザーにフォローボタンを出さない
Merge pull request tootsuite#99 from pixiv/autoresize_textarea
autoresize textarea
replace oops image
謎の clear: both; を削除
Update accounts.scss
add tests
Remove unused translation
Merge pull request tootsuite#98 from pixiv/media_aspect_ratio_change_to_16_9
media aspect ratio change to 16:9
add rel=nofollow
fix character escaping in URL
Merge pull request tootsuite#90 from pixiv/sidekiq-statistic
Merge pull request tootsuite#96 from pixiv/admin_script
Destroy local account from admin page
Merge pull request tootsuite#92 from pixiv/fix/translation_ja_modal
about.termsにするとどうか?
フィードバックを受けて翻訳を微調整した
@joshp23

This comment has been minimized.

Copy link

joshp23 commented Jun 18, 2017

This is the main reason that I'm not using Mastadon. Groups are a wonderful feature of GNU Social, and I would love to see them implemented on Mastadon.

However, while that certainly does keep me from enjoying Mastadon, the root of the matter is that...

  1. This is an opinion (subjective) based exclusion of an established feature that many, myself included, find far more valuable than is implied above, and not at all visually irksome. "My personal, subjective opinion is better than yours because I hold it," is not a good reason to exclude an established feature set.
    • Also, it is entirely possible to avoid groups if you so choose when they are implemented.
  2. Treating subjective opinions as objective truths (ie, "It is my opinion that this provides little value, it is therefore a fact that this is so,") is just bad directional thinking.

This, being an old and closed issue, likely doesn't get the attention that it deserves, but I know that I am not the only one that holds this view.

At any rate, It would be great to see groups in Mastadon, please reconsider.

@Gargron

This comment has been minimized.

Copy link
Member

Gargron commented Jun 29, 2017

Reopening, but not high priority.

@Gargron Gargron reopened this Jun 29, 2017

@ykzts ykzts added enhancement and removed wontfix labels Jun 29, 2017

abcang pushed a commit to pixiv/mastodon that referenced this issue Jul 3, 2017

@schiessle

This comment has been minimized.

Copy link

schiessle commented Sep 16, 2017

Coming from GNU Social I also miss groups a lot. It is a easy way to exchange messages about a specific topic without the need to follow all the people (and also get all the unrelated messages).

But after thinking about it for a while I wonder why there is this arbitrary distinction between groups and hash tags? Maybe it would be better to simply add the possibility to follow hash tags, similar to Diaspora. It achieves the same but makes it probably easier to use and understand for new users.

@Cassolotl

This comment has been minimized.

Copy link

Cassolotl commented Sep 16, 2017

Maybe it would be better to simply add the possibility to follow hash tags, similar to Diaspora. It achieves the same but makes it probably easier to use and understand for new users.

I agree! And @schiessle, that's #1096, if that helps at all.

@joshp23

This comment has been minimized.

Copy link

joshp23 commented Sep 16, 2017

I think that either option (following hashtags or creating groups) is a good idea. However, groups has a potential edge in viewership/participant restriction.

takayamaki pushed a commit to takayamaki/mastodon that referenced this issue Oct 1, 2017

@fsnk

This comment has been minimized.

Copy link

fsnk commented Oct 11, 2017

I would very much like groups.

I think they would help users find other people who share their interests, especially since Mastodon by design limits discoverability by not allowing full text search, and other social media platforms have been training users off hashtagging. (Twitter no longer requires a post contain the actual hashtag in order to appear in the hashtag search results.)

@schiessle

This comment has been minimized.

Copy link

schiessle commented Oct 12, 2017

I heard rumors that groups might come in one of the next releases. 😉
It would be good to learn from the mistakes of status.net aka GNU Social which are in my opinion:

  • on GNU Social there can't be a group "foo" and a user "foo". Would be great if the namespace would be decoupled so that it is possible to have users and groups with the same name.

  • GNU Social has group aliases. So you can have for example a group for all FOSS enthusiasts and let them address the group as !FreeSoftware !OpenSource !FOSS or !FLOSS. I think this is great and useful in many areas. But on GNU Social this aliases are only available on the server which hosts the group, all other servers only know the main group name. If we have group aliases it would be great if they would federate as well.

@deutrino

This comment has been minimized.

Copy link

deutrino commented Nov 15, 2017

There is a fair amount of discussion on the merit of !groups on #1096 in case anybody missed the link to that issue upthread.

@Cassolotl Cassolotl referenced this issue Nov 26, 2017

Closed

[Accessibility] !bangs #5824

1 of 2 tasks complete
@Cassolotl

This comment has been minimized.

Copy link

Cassolotl commented Mar 4, 2018

I note that option to follow hashtags 1096 Ability to subscribe or follow tags #945 has a lot more thumbs-ups than this one, despite this issue being much older. I'm wondering if there is a plan to implement both? I know that !groups is on the roadmap for the near future, and I'm concerned that that's instead of the ability to follow hashtags?

Edit: It was pointed out that #1096 is a duplicate, but I think my point still holds! #1096 has 35 👍 and #945 has 13.

@deutrino

This comment has been minimized.

Copy link

deutrino commented Mar 4, 2018

Is #945 an implementation of #1096?

Also, there's the wrinkle of groups, as implemented in gnusocial, making sure the messages sent to the !group will federate to all subscribers. Following hashtags doesn't do that.

@Cassolotl

This comment has been minimized.

Copy link

Cassolotl commented Mar 4, 2018

Sure! :)

So, when I used !groups on GNU Social, my main feeling was that they were pretty confusing. It required someone to set it up, and there could be three groups with the same name on three different instances all with different rules about who can join. If an admin made a group where members (followers and posters) had to be approved, and then the admin became inactive, the group just became stagnant forever.

So it seemed to me like following a hashtag might be better, because there were no leaders and anyone could keep joining in without having to wait for permission.

So it's a pros and cons situation. Someone could spam a bunch of people following a hashtag, whereas in a !group the admin/group leader could stop that happening by removing a spammer from the group and revoking posting rights.

Also deutrino pointed out that if you're part of a !group on any instance then messages from the !group get to you even if you're not following anyone who posts to the group, whereas with a hashtag search you might never see a post in that hashtag if you don't follow or share an instance with anyone who uses it.

So I guess I would like to be able to follow hashtags regardless, because there are some hashtags I always want to have pinned columns of, and pinned columns can get unwieldy and require a lot of scrolling so I'd rather all the toots were just rolled into my home feed. I don't think that !groups are a good solution to that for me, because I would rather risk spam and avoid the complications of group administration.

Overall they're kinda the same - having posts about a particular topic in your Home feed regardless of whether you're following the people involved. But they seem to each be useful in different ways, so I don't want one to replace the other. I welcome more thoughts/ideas/discussion/comments if anyone has them!

@joshp23

This comment has been minimized.

Copy link

joshp23 commented Mar 4, 2018

Groups federate. That's the main difference that I see. Secondly, groups can be made private.

@nightpool

This comment has been minimized.

Copy link
Collaborator

nightpool commented Mar 4, 2018

@Cassolotl the main problem is that it's very, very hard to try and solve the problem of having hashtags federate out for discoverability. The main reason I see to implement groups is that it allows people who are on brand new instances or don't have any followers to find people who want to see their posts! and with hashtags, there are a lot of thorny problems of "well, who is following this hashtag, how can we know that they're following it on a tech level, and how do we get posts to them". Groups solve these problems, but they come with their own downsides. Following hashtags is useful, but the main reason to go with groups is to help new user discoverability, and right now implementing that for hashtags would be very hard.

ideally we would have both. But i think of the two, i think groups are more useful for us right now.

@Cassolotl

This comment has been minimized.

Copy link

Cassolotl commented Mar 4, 2018

Since they are different and have different purposes, I do hope we can have both. I'm not denying that groups are good for various reasons, obviously there are plenty of people into the idea and Gargron is apparently more up for it now. But clearly there are also plenty of people who'd like to be able to follow hashtags too, so I'm just hoping that adding groups won't mean that following hashtags becomes a forgotten feature request.

Edit:

The main reason I see to implement groups is that it allows people who are on brand new instances or don't have any followers to find people who want to see their posts!

A lot of these people will be brand new users, and I definitely agree that them having some groups to follow would be excellent for helping them get settled in. Mastodon has so far been much more new-user-friendly than GNU Social, so I imagine folks will have an easier time finding and joining groups on Mastodon than I did on GNU Social? I do look forward to finding out how it all turns out.

But yes, follow hashtags. I don't want it to be forgotten.

takayamaki added a commit to takayamaki/mastodon that referenced this issue Mar 6, 2018

Enable showing trend tags on the WebUI (tootsuite#139)
* Display trend tags on the WebUI

* move fold state of the trend tags list into props

* use <ol>
@LEW21

This comment has been minimized.

Copy link

LEW21 commented Apr 3, 2018

Groups are the killer feature of Facebook, and are probably necessary if we want people to migrate from Facebook to Mastodon massively.

I've invited people from a Polish IT group ("Jak będzie w Maszynie Turinga") on Facebook to Mastodon, and used hashtag "#turingi" to "recreate" the group on Mastodon. Unfortunately, people on other instances don't see all the posts there, and that's a major roadblock. Additionaly, if this migration would succeed, we would probably have a problem with spam - as the Facebook group is moderated, and useless posts are getting removed - which we can't do with a hashtag.

@hcs0

This comment has been minimized.

Copy link

hcs0 commented Apr 20, 2018

I would like to see this feature. I recently tried out GNUSocial and I love the Groups feature (I have one just for travel) and would love to have something like this available in Mastodon too.

@Gargron Gargron changed the title support groups using bangtags Support groups Apr 20, 2018

@semente

This comment has been minimized.

Copy link

semente commented May 4, 2018

The global and local public timelines are now flooded by a huge amount of new young Brazilians and they share a common interest (they are part of a fandom community leaving Twitter after some rules changed there making some of them loosing their Twitter accounts).

As Portuguese speaker I noticed that what these new users most enjoy in Mastodon are the public timelines - or the ability to interact with an audience outside their followers circle. Looks like they are the majority of active users on Mastodon now hahaha and because of that they made the Federated Timeline like their chat channel (and many believe it is "their channel": they often complain about "gringos" and other people they don't share the same interest like being intruders).

Based on that I think the ability to follow different public timelines makes more sense now.

Some thoughts and opinions:

I don't like how "groups" are implemented in GNU Social. The use of !bangtag syntax to post make the post dirtier, and it compete with hashtags. Also I don't think "group" is an accurate name for what I have in mind (and forgive me if I'm missing the point of this Issue). "channel" or "public timeline" may fits better.

In my opinion, private groups and communities are already possible with separated instances.

And the ability of following hashtags may be interesting, the existing UI ability to pinning hashtags, for those that do not want mess with your personal timeline, helps. I believe that once people are able to follow hashtags they will start using it more effectively instead creating many nonsense tags or using different hashtags for a same subject.

@Cassolotl Cassolotl referenced this issue May 26, 2018

Open

Feature proposition : Private hastags #4513

1 of 1 task complete
@pwFoo

This comment has been minimized.

Copy link

pwFoo commented Jul 13, 2018

Private groups would be awesome for some of my needs...
But separated instances would be waste resources I think?

@pwFoo

This comment has been minimized.

Copy link

pwFoo commented Jul 15, 2018

Maybe technical easier could bei a list based group feature?

Copied from private hashtags issue #4513

Maybe instead of private hashtags visibility by list members? A list is a timeline / stream filtered by users.
List users -> group members

So lists could be additional visibility / access filter like public, followers only or direct?

Select a list to share direct to all list users (shortcut for mention all the users to Post direct / private).

If that would be possible it would be great to have a way to share a list (group) with all the users (group members) to the members.

@joachimesque

This comment has been minimized.

Copy link

joachimesque commented Aug 22, 2018

There's one remark I read from time to time when new people join Mastodon, is “we should make a new instance for design/photography/veganism/my city”… these ideas would be better served by groups, as I would only require one account for many groups.

I see groups as closed groups, where discussions are not shown on local/global feeds and you have to be approved to join in. That might mean some kind of moderation panel for group owners, which complicates things exponentially. "Open" groups would be served by followable hashtags (see #1096) or something of the sort.

Groups were the main feature I used on Facebook before I left the social network, and it's something I'd like to see it on Mastodon, too.

@duven87

This comment has been minimized.

Copy link

duven87 commented Sep 25, 2018

Yes! it would be nice finally a decentralized social network with groups and with the posibility to follow them.. I prefer follow groups and channels than people :)

@pwFoo

This comment has been minimized.

Copy link

pwFoo commented Oct 6, 2018

Instead of build a group feature would it easier to build it with "shared lists"?

  1. Build a mastodon list with users / members
  2. Add feature to share the list (copy / share to list member users)
  3. Share to list members (would be a new mastodon feature) as done with visibility modes "followers only" or "direct"

That isn't a closed group, but make it easy to share private to some users.

@nemobis

This comment has been minimized.

Copy link

nemobis commented Oct 11, 2018

Groups are also the one thing that Mastodon lacks compared to Google Plus, which could prevent some closed/invite-only/moderated communities from migrating.

@Angular-Angel

This comment has been minimized.

Copy link

Angular-Angel commented Nov 3, 2018

Hmm. I've been thinking about this, and I think it would be really helpful. Also maybe look at the functionality for forums and listings? Depending on how things are implemented those could be basically the same things as groups. Or they could be different. Being able to use mastodon for the same kind of functionality as freecycle would be really cool, though that might be getting away from it's core functionality. :/

@Tjoppen

This comment has been minimized.

Copy link

Tjoppen commented Nov 14, 2018

Small idea: put !groups as their own timelines next to the local and federated ones in the main UI. And in the user's own timeline of course :)

To those suggesting using hashtags as groups: hashtags can't sew the fediverse together the same way bangtags do. You can't moderate a hashtag and you can't link hashtags together. Thinking like that is a twitterism.

Groups can also bring instances together that wouldn't otherwise talk to eachother. If I follow !electronics@example.com from my cybre.space account, I might see people from scholar.social also post to that group. But I would probably not see them if I used a hashtags, since hashtags don't proliferate that far.

Groups are also a useful way to quarantine interactions with people who you wouldn't otherwise want to talk to, but are fine talking to about a certain subject. Example: we have an amateur radio group on our GNU Social instance. One of the guys in it is on an edgelord instance, and I can't stand him when he talks about non-radio stuff. But since the group keeps conversation to a topic, interaction improves.

Finally, groups could potentially be linked together. So posts might flow between !electronics@example.com <==> !soldering@hackerz.foo

GenbuHase pushed a commit to GenbuHase/Yzu-don that referenced this issue Nov 24, 2018

@hex-m

This comment has been minimized.

Copy link

hex-m commented Dec 17, 2018

Prismo is implementing a federated link aggregator (think of reddit). As they naturally need "groups" we should try to be compatible. There is a nice short article that gives an overview. Basically: "will follow the conventions for how GNU Social handles groups"

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