Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It doesn't exist yet. The best way the solve the platform overreach problem is replicating the podcast model, and transitioning from those platforms to two utilities:

(1) Content hosting (2) Content browsing

This way, the /r/BikeShedding community can buy a domain, say, BikeShedding.gg, and connect it to a content hosting platform that delivers a standard API + web UI. This is (1).

Users will have an app, let's call it FrontPage, in which they can put it a domain to subscribe to, or pick from a list, exactly like we can use podcasts app today to either add a manual RSS feed or choose from the library of feeds an app offers.

Podcasts are the pinnacle of decentralization yet I haven't heard once the word "federation" or had to choose an "instance".

If someone wants to talk about this more, email to anything at weedon and scott [dot] com. I did apply to YC with this, but it got rejected -- maybe the time is ripe.

Edit: Important to note that this works for all platform overreach cases -- Avoiding YouTube censorship, exiting Twitter's echo chamber, and yes, for Reddit as well.

The problem with federated platforms like mastodon is that they are still platforms, and platforms suck. You replace horses with cars, not with slightly better horses.



> Podcasts are the pinnacle of decentralization yet I haven't heard once the word "federation" or had to choose an "instance".

This is due to the difference between one way vs 2 way communication. Blogs and podcasts chose the word "syndication" and you use an RSS client to subscribe instead of an instance that can talk back.

What your story doesn't deal with is accounts (not just logins). If you add that you pretty much land in the fediverse model (except in your story every subreddit would run their own userless instance).


Is a unified account important? For me, no, not really. In fact I think I’d prefer unique accounts per “subreddit”.

The way I see it, each “subreddit” is an independently run instance that I can authenticate with. Once it’s set up, my client handles the details of automatically authenticating me when I’m interacting with that instance. I’m imagining it securely stores the domain and token for each “subreddit”, though admittedly I haven’t given it any real thought.

As long as every instance is using some standardized protocol / API you’re set. A system like this is not only dead simple, but it opens up the potential for all sorts of really amazing frontend clients.

In addition to that, each instance could have a lot of control over which features they’d like to expose. For example, whether or not downvotes are allowed. They’d also be able to monetize in a lot of unique and interesting ways that aren’t possible on a centralized platform.


Very true. Still, it makes a big difference, to omit the jargon and the need to choose an instance. Even if under the hood the technology is the same, the users just know they sign in to an app and it works everywhere.

The content creator/moderator knows that if the hosting service starts acting iffy, he exports everything to a different host, keeps the same domain, no one knows he even moved. Much smoother.

The problem with federation is not the technology, is that the technology is packaged as a platform.


This sounds like kind of how Tapatalk works. Tapatalk forums are fine enough, so it's not a bad model.

I think there's a third piece missing though which is discovery/distribution. On reddit, popular posts from any sub can reach the front page, and perhaps more important, discovering new subreddits is a core part of the user experience. Users share new subreddits all the time, the site constantly pushes you to new ones, and they're easy to find with the search function. AFAIK Tapatalk doesn't do this, and it would probably not be welcome given the expectations they have with existing communities.


I agree with you completely, I always found federated platforms confusing to use and they still run into the same problems that billion dollar platforms have without the resources to solve or mitigate them.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: