So what is Subl, anyway?

So I’ve been talking about distributed social stuff a lot lately, especially Publ (my publishing engine, which runs this site, in case you are new here), and also ecosystem stuff for things like private entries and other things that have been pinging around in my head for a while.

A thing I keep on mentioning is Subl, but generally only talking about it tangentially without actually going into detail with what it even is. So, I guess I should talk about that at some point.

So, where Publ is about publishing, the idea behind Subl is that it’s for subscribing. I’m still using Feed on Feeds as my feed reader, but it’s gotten quite long in the tooth. While it’s been improved immensely by a few folks (mostly Alexander Schulze with some help from Justin Wind and myself), it still doesn’t quite scratch my itches for where I want to see distributed social to go, and adding in some of what I’d like to see feels like a pretty difficult proposition at this point.

Anyway, the original idea for Subl itself was that it should be the best possible RSS/Atom/feed reader. It would be a dashboard for reading content from other sources in heterogeneous ways as appropriate for the content (per the reader’s preferences, of course), and it would also serve as a private little node in a greater distributed social network. It should support item sharing (reblogging/commenting/favoriting), and it should integrate in with whatever friends-only functionality is supported by the originating systems. I figured it should support RSS and Atom at the very least.

I also figured that the UI and the backend should be somewhat decoupled, and there should at the very least be rich API support allowing third-party clients to talk to it, in order to support things like mobile apps and the like.

Well, in the time that I’ve been thinking about it (some of my earliest musings going back to 2003!), an entire protocol ecosystem has emerged around this stuff, which is quite promising. There’s a few protocols in particular which are worth looking at:

  • Microsub: Allows for a client to talk to a subscription engine
  • Micropub: Allows for a client to talk to a publication engine
  • IndieAuth: Distributed identity and authentication which allows authentication from a public profile page
  • AutoAuth: Allows for unsupervised app connections between systems (for e.g. identity federation)

And each of these things has a number of existing implementations! And all of them fall under the Subl umbrella. And I kind of want to do… all of them?

Anyway, at the moment I kind of see Subl providing a bunch of separate Flask components that can be brought together in whatever building-block-type ways. I see the following Flask components as possibilities:

Subscription engine (Subl)

This lets people subscribe to feeds and notifications. It would support RSS/Atom/h-feed (ideally with WebSub for push), Webmention (as an inbox), and AutoAuth (for private content per my last ramble). Users can designate these incoming notifications to go to different destinations – for example, “comics,” “news”, “notifications,” “stream.” Auth requests would get served up as a virtual stream of notifications, as well.

I would also want it to support RFC 5005 (backfilling content) and 6721 (deletions).

The user-visible web view of Subl itself would probably just be a subscription dashboard, because actual reading would happen in…

Reader (Subl-Reader)

This is what would give people their view into their feeds. I see it as having different sections for each of the destinations, and each section could be configured with a different view characteristic. For example, I would configure my sections like this:

  • “Comics” shows everything that hasn’t been marked read in an oldest-to-newest manner
  • “News” shows everything that hasn’t been marked read in a newest-to-oldest manner
  • “Stream” shows everything newest-to-oldest
  • “Notificatons” would show Webmentions in a reasonable manner (e.g. sorting all entries by most-recently-mentioned, with a favorite/boost/reply summary and a link to see details)
  • “Inbox” would just show all reply/comment Webmentions newest-to-oldest

and so on.

It would also allow the user to send Micropub events to a microblog from here; for example, boosts, favorites, quote-boosts/comments, and replies. This mechanism would respect privacy settings on the individual items, and also allow the user to apply privacy settings to the microblog posts.

And, while we’re at it, why not support multiple MicroSub sources and Micropub targets? No sense to limit your view to a single public profile!

Profile/microblog (Subl-Profile)

This would be a profile service which gives people an entry point into the IndieWeb if they don’t already have a website of their own; this would essentially serve as the “instance” or be an identity provider or whatever.

Basically it would give people the ability to log in – via username/password or OAuth or IndieAuth or whatever – and provide an IndieAuth endpoint. People could fill out links to their other social services and websites and whatever and put up an “about me” sort of thing.

And then the microblog is basically Twitter/Facebook/Tumblr posts. Short-ish status updates, with full Webmention support, allowing posting via Micropub. Media could be attached as well; photos, videos, music, whatever. It would also provide h-feed and Atom feeeds and WebSub notifications.

It would also support IndieAuth for people to log in to see private content (again, per current design thoughts), and have mechanisms for users to categorize those logins into access groups and so on. This would also provide a notification feed to the subscription engine telling people “hey you have a new follower” so that they can decide what to do with privacy groups.

The big picture

So, if someone signs up for the microblog/profile service, they would automatically get set up with the reader, with all of the endpoints set correctly.

But someone could also sign into the reader with their existing profile provider. If that profile provides a Micropub endpoint, then they would get all of the reblog/comment/etc. functionality that’s expressed by that endpoint.

The main things I see needing to happen for this world to work out:

  • Extend Micropub with privacy-management functions, including (but possibly not limited to):
    • Get follower list
    • Get groups
    • Create/edit groups
  • Extend MicroSub with a friend/follow request notification
  • Extend MicroSub with the privacy stuff

Fitting it together with Publ

The great thing is that if these are all done as Flask components, they could also be plugged into a Publ instance – or any other Flask site.

On that note, I also want to make a Micropub endpoint for Publ, to support reblogging and deeper commentary (as well as having the ability to use good mobile Micropub apps to post content in the first place).

This isn’t to say that Publ would be the profile component for Subl. While it would certainly work to have a Publ category for streamed updates, I’d personally want to keep my social-stream stuff separate from my main site (especially since I don’t want my 200-character musings to spam peoples' traditional RSS readers). This is why the reader absolutely should support multiple Micropub endpoints so I could post quick replies to other people on my social feed while also getting the ability to do more long-form/structured content through my main site.

While on the subject, a Micropub endpoint for Publ would be a good stepping stone to giving easier multi-author support to Publ. Currently Publ does support multiple-author blogs, but it requires a lot of author trust right now; basically I could give write access to my site’s git repo to anyone and they’d be able to write articles… and edit my articles… and change my templates… and so on. But if Publ had a Micropub endpoint that could be configured to limit certain authors to certain areas, and force their Author: and Author-URL: headers appropriately, this opens up a lot more possibilities for simple community blogging.

Next steps

But all in all I feel like Micropub for Publ is a lower priority. If I were to start on the above stuff I’d probably focus on the subscription engine (which could then be used in tandem with one of the existing readers out there) before doing the reader and profile components. And then those three things together would be amazing.

Also, what I’ve outlined above means not needing to leave old social media behind! It would work just fine with anything that supports RSS and Atom, including Tumblr and Mastodon, out of the box (although Mastodon subscriptions would only get public posts until someone adds in the auth support). And of course plenty of adapters exist to get YouTube, Facebook, and Twitter via RSS/Atom as well.

The main scaling bottleneck would be the subscription engine. That’s also where most of the interesting problems seem to live, e.g. things like managing identities on subscriptions and so on. Like I guess you’d need the ability to specify which identity (if any) you want to subscribe as? What if you want to subscribe by multiple identities? Do you then get entirely separate feeds, or do you get the union set of what the various identities would see? And so on. That could be where things all fall apart very quickly. But it does feel like the part I should work on next – if I ever actually have time to do so.

I also see the following things shaking out for Publ:

  • Publ-Editor: an online editor and Micropub endpoint (or maybe this could be called Publ-ish, finally completing the Terrible Pun)
  • Publ-Push: basically an adapter so that Publ can (finally) initiate Pushl pushes on its own (rather than going through a cron job), as well as providing the auth stuff necessary for private Webmentions to work

    It’s worth noting that I built Pushl with this intention from the beginning, with the command line tool mostly existing for others to be able to use it outside of Publ. Maybe I should, like, work on doing the actual integration at some point. (But for now my silly cron job is fine.)

Comments