Aggregating the Decentralized Social Web

In the wake of recent FCC plans to repeal net neutrality regulations, people are starting to talk about decentralization, both of infrastructure and of the platforms we use to communicate on the Internet.  The latter has moved more quickly than the former, since it’s arguably easier to write code than to lay fiber optic cable.  In the last few months, I’ve experimented with :

  • Mastodon
  • Beaker Browser
  • GNU Ring
  • Matrix
  • ZeroNet
  • RetroShare
  • Twister
  • Patchwork (SSB)
  • Friendica

Note that those indicated in italics are more web replacement than social network platform.

That’s quite a few apps to open regularly.  Wouldn’t it be nice to aggregate this content so you could follow everything from one app. There have been some attempts at this (seesmic/tweetdeck/etc.) aimed at the major commercial social networks, but , since feeding into an aggregator undermines the revenue model of the social network (remember how Twitter used to support RSS?) they were either acquired or left to wither. Since decent platforms don’t have a revenue model to protect, why can’t they be more aggregation friendly? Mike Caulfield suggested that smartphone OS’s were functioning as aggregators via notifications.

There are actually three problems to solve, reading, which is relatively easy,  posting, which is harder, and social graph management, which is quite complex

Reading various streams in an aggregator would be most easily accomplished if various decentralized platforms would support stream output as password protected RSS.  Twitter was on the right track before revenue growth got in the way.  Subscribing to my personal timeline(s) with my favorite RSS reader would bring everything together, especially if I had a reader that listed items chronologically independent of source.  The potentially difficult part is dealing with and indicating private v public messages.

Posting is more challenging.  Not only does the client need to implement correctly the API’s of various platforms and keep track of what options and constraints to present to a user depending on which platforms they were posting to.  It looks as if Withknown has made some progress in this area with syndication plugins.

Managing your social graph is sort of the next level.  One of the disadvantages of centralized social networks is that Twitter/Facebook/etc. maintain your social graph and can therefore mine it for data and monetize it.  Several years ago, VR celebrity Mark Pesce (famous for his invention of VRML) did some development on Plexus, software that he described as “plumbing for the social web.”  The premise here was that your social graph would live on your device.  This would be possible because you would create multiple accounts on each social network, one for each friend/follower relationship.  Highly compartmentalizing your social presence is good for privacy but makes discovery more challenging, as software on your end has to parse your streams and sort out connections on your social graph.

How do we decentralize the web without so decentralizing our own social presence that it becomes unmanageable?

5 thoughts on “Aggregating the Decentralized Social Web

  1. Aggregating the Decentralized Social Web by Jason Green (þoht-hord)

    There are actually three problems to solve, reading, which is relatively easy, posting, which is harder, and social graph management, which is quite complex.

    Some brief thoughts:

    There are actually three problems to solve, reading, which is relatively easy, posting, which is harder, and social graph management, which is quite complex.

    I might submit that posting is possibly the easiest of the three and that the reader problem is the most difficult. This is based on the tremendous number of platforms and CMSs on which one can post, but the dearth of feed readers in existence.

    Managing your social graph

    Something akin to a following list could help this. Or a modified version of OPML subscription lists could work. They just need to be opened up a tad. Some are working on the idea of an open microsub spec which could be transformative as well: https://indieweb.org/Microsub-spec

    How do we decentralize the web without so decentralizing our own social presence that it becomes unmanageable?

    You’ve already got a huge headstart in doing this with your own website. Why bother to have thousands of accounts (trust me when I say this) when you could have one? Then, as you suggest, password protected RSS (or other) feeds out to others could allow you to control which audiences get to see which content on your own site.

    It looks as if Withknown has made some progress in this area with syndication plugins.

    WordPress has lots of ways to syndicate content too. Ideally if everyone had their own website as a central hub, the idea of syndication would ultimately die out altogether. At best syndication is really just a stopgap until that point.

    Subscribing to my personal timeline(s) with my favorite RSS reader would bring everything together,

    I’ve written some thoughts about how feed readers could continue to evolve for the open web here: http://boffosocko.com/2017/06/09/how-feed-readers-can-grow-market-share-and-take-over-social-media/

    listed items chronologically independent of source

    Having a variety of ways to chop and dice up content are really required. We need more means of filtering content, not less. I know many who have given up on chronological feed reading. While it can be nice, there are many other useful means as well.
    Syndicated copies to:

    Author: Chris Aldrich

    I’m a biomedical and electrical engineer with interests in information theory, complexity, evolution, genetics, signal processing, theoretical mathematics, and big history.

    I’m also a talent manager-producer-publisher in the entertainment industry with expertise in representation, distribution, finance, production, content delivery, and new media.
    View all posts by Chris Aldrich

Mentions

  • Jason Green

Leave a Reply

Your email address will not be published. Required fields are marked *