EARLY DRAFT 0.3

 

Distributed Social Following Mechanism

 

This document is a very EARLY DRAFT.

 

This document proposes an Internet standard mechanism for individuals to follow other individuals across multiple websites and social media platforms, that survives the person being followed transitioning between social media platforms via a distributed and robust mechanism.

Introduction

Motivation

Social media leaders (“personas”), over time, collect a following of “followers” who may read their messages, watch their videos, and support them financially.

 

Sometimes these leaders move to another platform. This happens for many reasons: platforms sometimes cease to operate; Personas sometimes switch to a different platform due to feature set or cost; platforms sometimes permanently ban users based on community guidelines.

 

In such cases, as it stands currently, personas lose their audience.

 

The particular case of Mastodon is especially egregious. Moving from one mastodon server to another causes a complete loss of followers.

 

Asking users to switch to a new service is not a tenable solution. Many users will not bother.  It is also rife for abuse, as users cannot be sure they are being asked by the same person they were originally following.

 

Thus a form of indirect addressing is sought after.

Desirable Traits

The following traits of a new mechanism are desirable:

 

Indirect Addressing: Followers should automatically be directed to the new service URL without special action on their part.

 

Open Standards: It is desirable that the mechanism be an open standard for numerous reasons. In particular, open standards foster competition among providers of technological solutions, which increases reliability of the mechanism.

 

Robust Infrastructure: The infrastructure providing the mechanism itself should be robust, such that it is not itself expected to cease to operate or become banned.

Broad Application: The mechanism should be broadly applicable across all kinds of Internet sites and resources such as websites, social media, and payment mechanisms.

 

Reverse Attestation: It would be desirable that if a persona claimed that they are operating from a particular social media account, that this is proved (e.g. that they are not claiming someone else’s account).  This property is not strictly necessary for following, but some might mistakenly assume this property is provided.

Overview of Mechanism

Publication of Social Media URLs in DNS

We propose that personas publish their current Social Media URLs in a set of DNS records against an email address as follows:

For username@domainname the DNS zone for domainname should contain a TXT record for the username node.  The content of that record should contain information about the social media URLs in a format specified later on in this document, starting with the string “social=”.

The records in bind format for the given domain might look like this:

 username        IN     TXT     social=SOCIALMEDIAINFO

 

Note: these DNS nodes have nothing in particular to do with sending or receiving email. These “email addresses” do not need to be used for email. They could, for instance, be something like DonaldTrump@FollowThisPerson.example.com which would only be used as their public address for the following mechanism, and not for email.  However, nothing stops an actual active email address from also being a following address.

DNS is robust for several reasons. First, as a fundamental part of the Internet infrastructure, it is likely to persist for the long term.  Second, it is distributed.  This means that if a particular domain service fails, the mechanism still works in general for all other users of the mechanism. Only users on that particular domain are affected.

Should users concentrate on a well known domain like FollowThisPerson.example.com, robustness suffers.  Ideally people should use their own DNS providers, or distribute themselves across many user-friendly providers of the mechanism.

User Agents

User agent software can be provided such that users who follow other users can automatically find the persons they follow.  This can be a local application, a browser plugin, or a web site catering to this service, or otherwise. In particular, users must keep (or services must keep on a user’s behalf) a list of DNS domains they are following, and the user agent should provide direct links to the persona’s services.

For the example above, one might add donaldtrump@followthisperson.example.com to the list of people they are following. The User Agent would then perform the DNS lookup to find the actual current Social Media URLs cooresponding to the person being followed, and provide links for the user to click on.

Specification

The specification of the TXT record social media URL information (format and encoding) is still TBD

Current thinking follows.

 

Social Media Type

Prefix

Use

General / Other

g

General social media sites such as Facebook

Home pages

h

Website homepages

Chat

c

Chat based sites such as Twitter and Gab, but also chat based services such as XMPP/Jabber and IRC

RSS

r

RSS feeds

Blog

b

Blog based websites such as wordpress sites, medium

Video

v

Video based sites such as YouTube, DailyMotion, Vimeo, and BitChute

Development

d

Development websites such as github

Funding

f

Funding services such as Paypal, Patreon, GoFundMe, SubscribeStar

Extension

x

Reserved for future use.  General sites should use General, not Extension.

 

Example:

social=h:https://mikedilger.com v:https://youtube.com/mikedilger c:https://twitter.com/mikedilger2 c:https://gab.com/mikedilger d:https://github.com/mikedilger g:https://keybase.io/mikedilger g:https://reddit.com/user/mikedilger g:https://news.ycombinator.com/user?id=mikedilger

 

To view this actual record from a linux terminal, run:

$ dig mike.mikedilger.com TXT

 

This record provides data to people who follow mike@mikedilger.com.  Within DNS, ‘@’ symbols are replaced by ‘.’ symbols, thus the lack of an ‘@’ symbol in the above linux command.

DNS records longer than 255 bytes are represented as multiple strings. These strings are to be considered together via simple concatenation.

All characters must be URL characters specified in RFC 3986 sections 2.2 and 2.3, as well as ‘%’ for percent encoding.  Percent encoding must be used to represent characters outside of the standard URL characters.

ASCII white space characters (and sequences of them) separate tokens.

Tokens consist of a prefix character (see table above), followed immediately by a colon, followed immediately by a URL, and end in the first following whitespace character or the end of the record.

To Consider