Social Media Meets RSS, v2

What Is Minifeed?

YOU want to control your social media feed. You want to own your follower lists. You don’t want to have to please the poor, pitiful moderators at some giant, cynical Silicon Valley behemoth. Just like on your blog, nobody should be able to shut you up—though, to be sure, they can shut you out of their own feed. In fact, if you leave Twitter, or Facebook, or whatever, you’d like to be take along your content and your followers and still have them, with just as much impact as they were having before. How could we make that possible?

Well, why not use the same open network that connects our blogs together—RSS—to connect our social media? That was the thought I had last January, when I posted “We Want to Pay for a Good, Functioning WordPress Microposting Plugin.”

The Knowledge Standards Foundation took on the project, and the first example microblog—or, as we call it, “minifeed”—was StartThis:

The new Minifeed theme turns a WordPress blog into a social media feed. StartThis happens to run on my own NAS sitting in a box at home and backed up offsite. It’s pretty cool to be able to control my own social media feed literally from the comfort of my own home. There are over a dozen other Minifeed installs, including one for the Minifeed project itself. You’re going to see a lot more popping up when we finish version 2. When v2 is ready, we’ll make it fully open source (both libre and gratis). It might just change the world…for the better. We’ll take back what’s ours.

v2: General Requirements

Just as I posted the requirements for Minifeed v1 on this blog, I’m going to post the requirements for v2 here too.

In the following, “mini” is short for “Minifeed”.

The first step of v2 is to create a social media reader. This is a big enough job that it might occupy all of v2, but we do want to go further to support cross-mini (or inter-mini) conversations as well as a notification feed. We will build the reader first, anyway. The basic requirements can be briefly listed:

• Follow and unfollow an RSS feed.
• Display only my (i.e., this mini install’s) posts—as at present.
• Feed reader: display my feed with posts from followed feeds (i.e., from other mini installs) intermixed with mine.
• If this is different from the foregoing, which it might not be: display other RSS feeds formatted as minis.
• Add inter-mini discussion threading.
• Support account mention features.
• Display mentions in notification feed.

Assorted feature requests associated with the above:

• The format for a mini account mention should be as in the Fediverse: @[email protected]. Thus my Twitter address is @[email protected], while my StartThis address is @[email protected], and my mini address is @[email protected].
• If I type a well-formed mini address, the software should attempt to find the associated RSS feed and account information. It should pop up the account information in a box, as Twitter does at present. I should be able to follow and unfollow the account from that interface.
• I should also be able to follow a feed simply by pasting it into a form (i.e., this is what you have already started developing).
• If I type @id with no domain, the software should attempt to identify that person and complete (shown on mouseover) the address if it is unique. If it is not unique, I should be forced to type the whole address.

I will continue to work on this post over the next few days to weeks, so let me know if you have any special (related) requests or ideas.

Following RSS Feeds

Requirements

In these requirements I distinguish between the act of following a feed and the display of the feed (the latter is covered below under “Feed Reader”). The basic requirements here are simple:

• Form allowing people to add a feed; verify that a feed is readable.
• Construct “followers” list from RSS messages that such-and-such is now following.
• Count, list, search, and delete items from a list of followed feeds; make these public by default, but include an option to make them private.

1. Add feeds to, and display, followed feeds list

• Design
  • On desktop/wider screens, the form should be near the top of the page in the sidebar.
  • On mobile/narrower screens, there should be a prominent button/link near the top of the screen (not at the bottom, at any rate). The form should popup/slidein (whatever we use).
  • The list of followed feeds should be linked from near the top of the account’s poster page, using the number of such feeds.
  • The list should be public by default, but should be easy to make private (like an obvious toggle switch)
• Functionality
  • Form should verify well-formed URL first, and give feedback to the poster, if there’s a problem.
  • Form should also verify that account is not on “blocking” list (i.e., list of accounts that have requested that you not follow; see “block self” just below). If the account is on that list, tell the poster.
  • The software should attempt to locate the RSS feed first at the given address, and then, bearing in mind that the poster might have supplied an incorrect path, in various locations using the poster-provided domain.
  • If no readable feed can be found, the poster should be told so.
  • If the feed is added, a notice to that effect should be given…maybe a slide-in from the bottom saying “@id was added” with a link to the followees list.
  • If the feed is added, an RSS message to this effect should be sent to the blog (see next).
  • Basic search.
  • “Unfollow as requested”: if account receives an authenticated RSS message from a followed feed, reporting that your account is blocked, respect this by unfollowing the feed.
    • Remove feed info from list of followed feeds.
    • Add same info to an always-private list of “feeds blocking me”. The link to this should probably be located at the bottom of the followed feeds (I guess?).
  • Eventually, allow accounts to respond to messages that they are now un-blocked.

2. Construct followers list

• Design
  • The button/link to the followers list should be prominent and near the top of the account’s poster page (as on Twitter).
  • The list of followers should be linked from near the top of the account’s poster page, using the number of followers.
  • The list should be public by default, but should be easy to make private.
• Functionality
  • Basic search.
  • “Block”: sends an RSS message to the follower.
    • Instructs the recipient’s Minifeed software to stop following. (See above.)
    • Unfollows the account, if was already following.
    • Adds account to list of “blocked feeds.”
    • Note: does not add accounts to “feeds blocking me” list. That is a distinct list.
  • Eventually, support un-blocking as well.

How to Decentralize Data Aggregation

One special difficulty about decentralized social media (especially such functions as counting likes and shares) is that it involves aggregating data across the entire network; for example, how do we calculate the number of “likes” of a post, if there is no master database containing all social media posts, and a function to count them up within a database? Can we do that without a giant central database? Centralized aggregators would make this possible, but they also place individuals at the mercy of much bigger organizations—ultimately, whoever does the job of centralization best will govern the network.

Besides, especially for smaller interactions among relatively few people, aggregators should not be necessary. The basic idea is to use a propagation model. The idea behind the strategy is simple:

• All social media data is connected to posts.
• Anyone who has a copy of a post, a reply, a like, a share, etc., is good enough as a source of the data as the original.
• It is much more efficient for people with updates to push those updates out than to check 1,000 followed accounts regularly (with “no” answers).
• BitTorrent is a P2P network in which anyone may be the supplier of a copy of a requested file. We might want to engineer a solution that uses that; Ology is working on something like this, so we should keep in touch with them.

In summary, one suggestion is that you push all updates to your own posts to BitTorrent, and you grab the data you need to construct your feed from BitTorrent. But exactly how it will work we leave to the engineers.

Feed Reader

Introduction

The feed reader (or just “feed”) is similar to, but to be distinguished from, the notifications feed (or just “notifications”). The feed reader displays, according to some algorithm (we can put them in reverse chronological order of receipt, to start), the posts of the feeds one is following. By contrast, notifications include replies, mentions, reposts, likes, and other items of interest to the poster which do not appear prominently in the feed.

In this, we are drawing the same distinction Twitter does. There is a good reason for doing so. A feed gives you new material to consider. The word “feed” is short for “newsfeed,” and a news feed gives you news, or discussion-starters, not the meat of the discussion. Your notifications, by contrast, are a feed in a derivative sense—a list of new posts and activity of interest to you.

Requirements

So here are the feed reader requirements, design and functionality combined:

• Account A keeps a list of all accounts that follow A (see above, “Construct followers list”). Then, “behind the scenes,” whenever A posts; or A posts a response to account B’s post, or to a post that B is mentioned in (see below); or A takes an action on account B’s post (see below); then A sends a push message to B (or perhaps to a pingback system, whereupon B fetches the message).
• Posts drawn from other sources are formatted the same as one’s own (but there could be an option to make one’s own posts appear differently, e.g., with a different background color).
• Within the main feed, all posts from all accounts that you follow are displayed reverse chronological in order of receipt, rather than reverse chronological order of original posting timestamp. Note, posts within a thread do have to be placed in forward chronological order of original posting timestamp.
• Local copies of all external posts are saved to the database as originally posted, unless they are edited or deleted:
  • An external post that is edited is updated in the database and reposted (although feed algorithms might deal with them specially) and specially marked (just how is a task for the designer).
  • External posts that are neither liked, nor reposted, nor responded to (in other words, the account does not touch them), are deleted after some period of time, once the database has gotten up to a certain specified amount of space. The database size is always kept below a certain editable limit.
  • The poster can delete individual posts from his feed. (This has no effect on the source post.)

Liking, Sharing, and Related Functionality

Threading

To be finished…

 

Notifications