Why a centralized Microsub server might be a good idea

Even though we have a lot of trouble with SPOA when @aaronpk breaks something accidentally, I think a centralized Microsub server could do some stuff that could be tricky to accomplish without it.

Centralized feed fetching

If one server fetches and sorts feeds for several people, we get a reduction of bandwidth for popular websites, which may be important in IndieWeb because some people like me host their sites on a low-power machines such as a Raspberry Pi.

Also we get some degree of anonymization for public feeds because feed is fetched only once without revealing the IP address of a person reading it - only the Microsub service owner’s IP is revealed.

Recommendation feeds

A Microsub server hosting several people’s feeds would be able to match categories that people are reading often and recommend blogs that post often with the same categories.

This one could be done with an external service too. It would also have the advantage of being able to work across Microsub servers, but may be not integrated so well.

The workflow I’ve envisioned requires a Microsub client that could subscribe you to a person by clicking on a button near their author card: 1. The user goes to a special “recommended” feed 2. The server gives them a preassembled feed of posts matching following criteria: author isn’t in any other feeds and the post tags are similar to tags appearing on the user’s feeds. 3. The user reads the feed and if they’re interested in a person, they click on their h-card and the reader prompts them to subscribe to this person.

Category feeds

A variation on the previous one: the user could subscribe to a category instead of a URL, and the server would be able to construct a feed of all posts it knows of with the same category.

This one, though, could also be replicated by syndication and external feed services.