tl;dr - Echommentary is a multi-site writer/reader with a crosscommenting "echobot" to unify discussion threads between multiple social media sites. Since all comments are echoed to other sites, everyone participates in the same unified discussion.
= = =
ECHOMMENTARY CORE FUNCTIONALITY
With the impending end of Google+, I've looked at various social media alternatives and have decided none are a perfect fit for what I really want. So...I'm rolling my own multi-site writer/reader solution. The features of the core system will include:
1) Echobot python console app uses web scraping or API to load new posts/comments from each source, to local storage. Core functionality is to scrape from your own profile pages, but you can also scrape followed profile pages to local storage.
2) Echobot echos new posts/comments to all other sources, so all followers participate in the same comment threads (rather than separate discussions on each site).
3) Local storage means it's possible to autopost everything to a new social media site/account if desired.
4) Ability to block users via delblock or shadowblock. A delblock auto-deletes comments by a user. A shadowblock simply doesn't echo a user's comments to other sites.
Project Echommentary's primary mission is to solve the problem of interoperability between diaspora, Mastodon, Google+ (while it exists), and other social media sites. It's an open source project so others are invited to help - especially with Python code for various sources.
There are, of course, a lot of products to multipost to many different social media sites, but these are more designed for commercial publicity rather than to foster cohesive community discussion. In particular, each copy of a post on the different social media sites has its own independent comment thread. I find this frustrating, because a lot of the best ideas are developed in comment threads, and only users from the same site will see those comments. Often, I find that one discussion thread on one site will have some interesting comments, while another discussion thread on another site will have other interesting comments. I wish that they could see each others comments!
So, my core idea is a comment echobot. It will take a comment from Sam on G+, and echo it on other sites with something that looks like:Sam @ GooglePlus:
Yeah, I noticed Aunt Cass in the sassy housewives ad. Actually a kind of subtle running theme of the movie that things on the Internet are often not quite true.
This is an "echo" comment, which appears to be made by the echobot user's account, rather than the original account. Unfortunately, this has some issues. For one thing, it may be best for the echo system to be opt-in. By default, everyone is shadowblocked. Their comments are NOT forwarded to other sites. But you could use a pinned post or something to ask folks whether it's okay to add them into the "echommentary" by echoing their comments to other sites.
Another issue - blocking. Let's say Anna wants to block Hans, so she never sees any comments by Hans. The problem is that she follows Elsa, and Elsa's echobot may echo a comment made by Hans on another site. Anna follows Elsa on G+, but Hans follows Elsa on Mastodon. Anna would see a comment on G+ like:Hans @ mastodon.social:
(@ Elsa @ mastodon.social) Hey Anna, chill out, babe!
The problem? This comment is seen on G+ as made by Elsa, not Hans. So Anna can't block these comments without blocking Elsa entirely. Unfortunately, the best solution may be for Anna to ask Elsa to block Hans. Elsa could block Hans with delblocking or shadowblocking; this prevents Hans's comments from being visible to Anna via echoing.
= = =
BEYOND THE CORE
The echobot stores what it scrapes to a SQLite3 database, as well as a static HTML file tree. This file tree is considered a source just like diaspora or Mastodon, but it offers no built in way to write posts or comments. It's mostly just for troubleshooting. Nevertheless, it can be a somewhat useful tool, and you can optionally serve it up with a web server for others to browse.
Far more flexible and powerful is the SQLite3 database, which stores all posts and comments, as well as their echoes (both pending and completed). This database can be accessed and modified by other programs, such as a writer/commenter, and a "universal reader".
My own interest is in a simple blog writer. It would have very basic functionality...just bold, italic, and inline images. This way, I could compose blog entries that would be directly inserted into the SQLite3 database for transmission to all sources. In addition to the basic functionality, I'd have automatic tag addition to include my own personalized hashtags. For example, if I have #myart
in the post, it would auto-add #ijkmyart
. That way, diaspora users could click on #ijkmyart
to see just my own "myart" posts - like a Collection.
With this simple writer, I could compose blog posts offline and then publish them when I'm ready or on a schedule. I'd still go to diaspora or somewhere to actually read and write comments. The big advantage of the writer is that it could be lean and mean - relatively simple to develop and modify.
A universal reader, however, could be a very powerful tool because it uses SQL queries. You could filter things in powerful ways, including blocking users in ways unavailable in the source systems (such as diaspora, which still lets you see comments made by a blocked user on someone else's post). You could filter followees by hashtag or content matches; you could filter out spoilers by hiding (temporarily) content matching a show you haven't caught up on yet. Stuff like that.
With a universal reader, you could define numerous "read only" sources - not your own profile pages, but followee profile pages. Maybe even blog pages also. Maybe even including RSS feeds, and such.
I feel like a universal reader/writer/commenter is a more complex project than a simple blog composer, but it's also something that a lot of people would really want. As such, it's important for me to think about the SQLite database design in a way that accommodates it from the start. In particular, it needs to understand that some sources are read/write, while other sources are read only. The user owned read/write sources are all that's needed for Echommentary's core functionality, but followed read-only sources are critical for universal reader/writer/commenter functionality.
= = =
AND BEYOND ... ?
Project Echommentary could be taken a step further to become its own independent peer-to-peer social media network, by exposing read-only SELECT functionality to a custom port. That way, echobots could directly pull posts/comments from each other's SQLite3 databases. Even with no outside sources, it could be possible to create an independent social media network somewhat similar to USENET - each node connects with a small number of trusted neighbor nodes.
One node connects to another node via an encrypted (ssh) connection, and then each node can send SELECT statements to the other side. Each node can pull new posts and comments. The reason I specify that it goes both ways, is because of the problem of NAT routers. Most users are behind NAT routers, and there's generally no way to connect to a "server" behind a NAT. But a user behind a NAT can connect to a server out there with a true permanent IP address (either standalone or behind a specifically configured router). So, only a small fraction of nodes need to be out there with permanent IP addresses.
Now, this is truly ambitious. But is it even necessary? I hope not. It's not like we desperately need yet another internet protocol "standard". But it's a potential thing to do which might be useful just in case.
= = =
The core Echommentary echobot will be a simple Python console program, to make it very portable and easy to develop/run/maintain remotely. Remote troubleshooting can be assisted by running Python's built in http.server on the local storage file tree. But for most users, it will be easiest and best to simply run and maintain it locally. Using SQLite3 makes it possible for savvy users to do a lot of powerful things with the database directly. I do understand that not everyone knows SQL, though.
For the universal writer and reader, I think that a native Python program would be better than web based...but I'm not sure. I feel like it would streamline development to keep most everything Python + SQLite3. Avoiding web based client functionality means avoiding a lot of extra complexity, maybe - and also it could be more readily adapted to mobile iOS/Android versions.
= = =
So, anyone interested in contributing, or just suggesting thoughts? Concerns?