Abe Orchard Limited

This is me on Mastodon

Public vs private messaging

Twitter - Assumed public. Everything with the exception of private messages is public and searchable

Whatsapp - Assumed private - Everything is only available to the users that are sent it.

Facebook - A mix - Messenger messages are private to reciepients, Posts on timeline are limited to those that they are shared with but can be public, Posts in groups available to anyone who joins the group (dependent on admistrative control) 

Mastodon -  Assumes that the instance is a relevant scope of for the user. 

Publishing levels

• Public - Listed in Local and Fenderated streams - for instances that share followers
• Unlisted - Not included in Local and Federated streams (How is the exclusion from Federated streams enforced?) but anyone can view
• Followers-Only - (How is the exclusion on Federated streams enforced?) only displayed to followers When combined with Follower lock allows you to control who can be a follower and hence allows you privacy on posting -
• Direct - Private message

Mentioning someone allows them to see the post.

Search

Is content able to be indexed by exterrnal websites (Can content be accessed when you are not logged in?)

Twitter - Generally Searchable,

Facebook - Not able to be searched, accessed when not logged in

Mastodon - Public content is searchable

Identity

Facebook - requires real names - Single accounts per person, No bot accounts
Twitter - User identities, bot accounts
Mastodon - User identities, bot accounts

Muting & Blocking

Twitter

Facebook - Ignore, Unfriend

Mastodon - Mute, Block

Blocked user’s side:

• The user is forced to unfollow you - Does this really only make sense if you have activated Follower Lock?
• The user cannot follow you - See above
• The user won’t see other people’s boosts of you - Does this include your public content
• The user won’t see you in public timelines - Unless they log out.

Blocking creates a class of users that have less access than an anonymous user. It therefore has trival circumvention techniques for content that you publically post (The effected user simply logs out or creats a separate profile).

Public Space vs. Private Space

The arguement for search

Enables likeminded users to find each other and conversations they would like to be involved in.

Encourages uptake of Mastodon by making it easier for new users to find reasons to be engaged within the platform

The arguement against search

There are a few main arguements against search.

The first is an argument about users finding conversations based on their existing relationships reducing the ability for user to insert themselves in conversations in a spammy way.

The second arguement is about protecting users from abuse or tracking or trolling (which seems to be focused around protection from personal abuse)

Thoughts on distributed search in Mastodon

The idea would be to allow instances of Mastodon to query the Elastic search indexes of other instances of Mastodon and for them to return any matching toots generated by their instance. This would allow instances (and users on that instance) to retain control over the findability of content they generate.

To do this would require:

1. Instances of Masodon to maintain an index of which other instances they will allow search queries from
2. Throtatling / query limits - To allow intances to manage the load of queries that they are responding to
3. Instances to only return Toots generated on their instance
4. Instances to mark whether Toots should be included in full text or hashtag searchs
5. Users to control which instances their toots may be searched / feerated to
6. Users to decide the audience for a toot (Global public & searchable, particular audience)
7. Instances to pass through the user for whom the search is being conducted on behalf of (and a way for the recieving instance to confirm that)
8. Instances to respect the audience definition when returning search results
9. Instances would need to compile results across multiple instances

Additional optional features

1. Instances could filter results based on NSFW or Senitive Flags
2. Instances could cache results and reuse where updates are not available or resources limited
3. Instances could return pointer to result rather than full result

Features of elastic search that support this approach:

User Personas

Posting User

Posting instance admin

Reading User

Reading Instance admin

Other User

Other Instance admin

Alternatives

• Instances could just make their content available to exterrnal search engines (Google etc.)
  Pros - No load on instance nodes
  Cons - Only public posts could be searched, tracking of users conducting searrch,

User Journeys

Posting User posts toot

Reading User who does not follow

Pros and cons of approach

Pros

Control retained by posting user

Content posted on an instance remains within the control of the instance with regard to search results

Followers could Optionally gain access to historical toots for people they follow

Cons

Admins of instances could still allow querting of federated toots

Large instances could overwhelm smaller instances

Search is not complete record

Thoughts, comments, things I didn't know about.

If you want to contribute to my thinking, enlighten me of the thinking of others more informed on the topic or generally just add to the topic message me on Mastodon

Alternatives

Trunk - Currated lists of users to follow

Relay servers - Bots that automatically copy toots from selected users to other instances that dont' have profiles following the users.

Related links

Christian Paul