Skip to content
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

Add profile directory #9427

Merged
merged 1 commit into from
Dec 6, 2018
Merged

Add profile directory #9427

merged 1 commit into from
Dec 6, 2018

Conversation

Gargron
Copy link
Member

@Gargron Gargron commented Dec 5, 2018

Fix #5578

  • Opt-in setting to be listed on a directory page ("Explore Mastodon"). Uses hashtags from profile bio
  • Local-only for now, so each server will only list its own opted-in users
  • Min. 10 followers required to appear on the directory to prevent spam
  • Sorts by most recent toot by default
  • Admin UI to see which hashtags are on the directory, and hide them if needed

Directory page:

image

Directory opt-in checkbox in "Edit profile":

image

Admin UI for hashtag moderation:

image

This should answer the question "how do I find worthwhile users from x without signing up and lurking there?" as well as "how do i find people interested in y?"

Toot asking for initial feedback on the idea: https://mastodon.social/@Gargron/101168486745315315

@Gargron Gargron added ui Front-end, design work in progress Not to be merged, currently being worked on labels Dec 5, 2018
@ClearlyClaire
Copy link
Contributor

Haven't actually read it, but there appears to be some leftover from your other PR regarding deletion_schedules.

Otherwise, I have two main worries:

  • I wonder how useful that thing really is without federating. I fear it would only be useful for big instances and further encourage them.
  • There were concerns about trending hashtags being used for harassment campaigns. Since this feature doesn't federate and you're planning to add ways for admins to blacklist hashtags, this seems like a lesser concern here, but I'd still ask around to get the people that were concerned by the trending hashtags feature before implementing this.

@ThisIsMissEm
Copy link
Contributor

Looking at this, I'm not sure if this is really the right approach. I think we're trying to solve two problems at once here.

One is how do I know this is a good instance for me? And the other is how do I find people I'd like to follow?

For the former, we could just do same aggregate stats around hashtags and profile hashtags; "Members of this instance use the hashtags of ABC, DEF, MNO, and XYZ", and "In the past week members have been tooting about #freedom, #tumblr, #winter. The hashtags that lead to the most interactions this month were #abc, #foo, #bar" (where interactions is likes + replies + boosts)

This way we're letting people know what they'll find here, without highlighting specific users.

For the second question, I think we she focus more around: who toots similar things to me and how may I know (friends of friends).

Admittedly this doesn't help with the cold start problem; but perhaps we could change onboarding to give you a six random hashtags to choose from, and then surface up random users who have used those hashtags and have more than a certain amount of toots / non-default avatars / followers.

Of course, as part of role out of this feature, I think we should do a mailout or other notification allowing people to opt-out of this functionality, explaining why we're adding it.

In order for mastodon to be successful, people have to be able to find their communities and engage with people who are interested in the same topics. Otherwise it becomes a very isolative experience, where people feel kinda lost & their home feed doesn't update often, so they don't check back or become sticky.

Additionally, I think Mastodon should build in the features of the friend finder from other networks, perhaps there's a way to do this with zero-knowledge of who the users are between instances (as to preserve privacy and still be decentralized)

@Gargron
Copy link
Member Author

Gargron commented Dec 5, 2018

@ThisIsMissEm Thank you for your feedback, but I think that's not what I was going for here at all.

First of all, the friends-of-friends, "who to follow" stuff is not something I want to go back into right now, so this feature is not intended to touch that topic at all. It's not about personalized results, but about finding people in general.

Nor is it about getting a feel for what a server is like. I want to reduce the need to sign up on different servers to experience their community (since that is a side-effect of the local timeline feature anyway). It's about you knowing that cybre.space exists and wanting to get some of the cybre.space vibes into your home feed on another server. How do you know who to follow? Here, look at this directory of cybre.space users who want to be found.

@Gargron Gargron force-pushed the feature-directory branch 2 times, most recently from 96085b7 to c888795 Compare December 6, 2018 03:58
@Gargron Gargron removed the work in progress Not to be merged, currently being worked on label Dec 6, 2018
@LoVicente
Copy link

Oh, I think I get it. So the idea is that a user wouldn't check their own instance's profile directory, because that's what the local timeline is for, but they would instead check other instances' profile directories for people to follow from there?
That makes more sense, but it felt a bit unintuitive.
I like the idea tho! 👍

@Gargron Gargron merged commit 73be8f3 into master Dec 6, 2018
@Gargron Gargron deleted the feature-directory branch December 6, 2018 16:36
@ThisIsMissEm
Copy link
Contributor

First of all, the friends-of-friends, "who to follow" stuff is not something I want to go back into right now, so this feature is not intended to touch that topic at all. It's not about personalized results, but about finding people in general.

That's fair, I know personalization of results is a very contentious topic, and one that'll spark much debate. However, I think it's something people expect, especially populations from mainstream social networks. Is there an issue for this, or should we start one?

Nor is it about getting a feel for what a server is like. I want to reduce the need to sign up on different servers to experience their community (since that is a side-effect of the local timeline feature anyway).

Do people really do this? To me, it seems that people pick an instance and roll with it, especially given the promotion of certain instances within certain communities (e.g., switter.at and sex workers on twitter)

I'm speaking only from personal experiences here, but I don't know anyone who's signed up to another instance just "to experience their community", as you can't experience a community without being part of it (to some degree) — I'm sure anthropologists have a phrase for this.

It's about you knowing that cybre.space exists

How does the new user of Mastodon know that cybre.space exists in the first place? Even when viewing a profile from a remote instance, it's not particularly highlighted in anyway. (Other than the "this information may be incorrect" warning)

and wanting to get some of the cybre.space vibes into your home feed on another server. How do you know who to follow? Here, look at this directory of cybre.space users who want to be found.

Would it perhaps make sense to surface the ability to add the local timeline of other instances to your own set of timelines? This seems like it'd probably be more useful than the full federated timeline of all instances.

I think we've still a lot of education to do with regards to instances and how they work for the mainstream internet population.

@Gargron
Copy link
Member Author

Gargron commented Dec 6, 2018

Would it perhaps make sense to surface the ability to add the local timeline of other instances to your own set of timelines?

I know this is really desired by many but there's no good way to do it. All current Mastodon features relating to other servers use ActivityPub. Viewing another instance's local timeline would require using the Mastodon REST API, which would play weird with Pleroma, Misskey, and any potential future project. Third-party apps can afford to do this because they are Mastodon apps and their decisions are very localized. If the Mastodon server started to use its API for federation, that would be worse. That's the showstopper for that feature in my eyes...

@ThisIsMissEm
Copy link
Contributor

I'm not saying doing this via server implementation, just via the client; or perhaps just add a way to get a filtered federated timeline by instances? i.e., only federated toots are available via the instance timeline?

This is just an idea, but really we've first to address the education about instances & introduce people to the fact that not all people are on the same instance as you.

@Cassolotl
Copy link

I want to reduce the need to sign up on different servers to experience their community (since that is a side-effect of the local timeline feature anyway).

Do people really do this?

I have done this a lot!

ladyisatis pushed a commit to pluralcafe/glitchcafe that referenced this pull request Dec 6, 2018
@ghost
Copy link

ghost commented Dec 7, 2018

I love this feature but against MIN_FOLLOWERS_DISCOVERY = 10. Spammers can easily and automatically register 10 users, but lonely newcomers rarely find their first 10 friends.

@deutrino
Copy link

deutrino commented Dec 9, 2018

That's fair, I know personalization of results is a very contentious topic, and one that'll spark much debate. However, I think it's something people expect, especially populations from mainstream social networks. Is there an issue for this, or should we start one?

#4870 (comment) :)

pluralcafe-docker pushed a commit to pluralcafe/glitchcafe that referenced this pull request Dec 11, 2018
hiyuki2578 pushed a commit to ProjectMyosotis/mastodon that referenced this pull request Oct 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ui Front-end, design
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants