i've been thinking a lot about The Side Project a good deal lately.
First off, let me note a few things.
1) At work, one of the things i've been working on is Push Notifications, which are short, semi-anonymous messages that can be routed to "you" (independent of where and what device you happen to be using at the time).
2) Twitter (the company) has become a real company and is starting to realize they need to make more money. This means they're doing things to gain greater control over the data we share with them.
3) Clients and User Agents are becoming a lot more powerful.
So one of the reasons i've been a bit radio silent is because i've been thinking about a way to combine all three of those into one. In essence, distributed Twitter. A decentralized short notification system that anyone can use.
The appeal of short public posts is pretty clear. Creating those messages and consuming them provides the correct dopamine effect that folks want. It's also important to recognize that there's a valid network effect that people enjoy as they converse among friends. Those are some of the motivators for why folks enjoy using those services.
The problems are that traditionally, you want all that data to flow through a centralized facility. This facility could provide metrics, but more importantly, it would allow the diverse individuals to find each other, connect, and keep the historical data associated with each. Of course, that means building out a scaled system that can handle terabytes of multi-indexed information per second. But, what if we didn't need that?
Protocols like Bittorrent have a simple "tracker" url that contains some meta information that allow peers to exchange information. Each peer could provide redundant copies of the information for the individuals of interest. Having the messages be short, and only keeping the last n number of messages "in circulation" would allow the data to be small enough to be easily stored and shared between clients. Yes, more popular "feeds" would be served faster than less popular ones, but i'm not sure that's bad. In addition, "repositories" could be created to act as reservoirs of data for some of the less popular feeds (with signatures or encryption providing some level of tamper-proofing).
Other protocols like TOR, don't need a tracker url to work, but can be very complex.
i would very much like whatever is being built to be able to run in the browser, either as a loadable web page or a plug-in, which tends to make me favor things like JSON and well known port addresses. Of course, that raises issues with things like firewalls and NAT routing, but fortunately, we have things like WebSockets to allow for persistent connections and SIP for some routing resolution problems.
Searching might be problematic, but then, feeds could opt into larger search engines to provide that sort of data search fairly easily. Again, reservoir sites could publish feeds as pages that would be pulled in, and potentially engines could become subscribers themselves to various feeds.
Discovery would happen pretty much the way it's done now, via discussion and republication. A user simply could click on a "subscribe" url associated with the republication or message index link, see that other user's data stream and optionally include it.
Ideally, feeds wouldn't need a centralized server for this. No company or group could say "That's not allowed" and throw up walls to prevent it. Someone wants to build a special app that adds kittens and rainbows to folks messages? Go for it. Someone else wants to build another that adds links to amazon products? Not like anyone can really stop them. Someone wants to encrypt their messages so that only key holders can read the content? Sure, go for it, that will probably screw the guy that's putting amazon links.
Mostly, i've been hashing out ideas on this, but i'm getting to the point where i think i need to involve other folks.
If folks are interested, i can create a collaborative document somewhere and invite folks in to work on it.
Anyone else interested?