Remember Jeremy, our fictitious content creator from the previous article. He came to visit me with Jim and Marc to discuss our reservations on the alternative blockchain-based social networks. They provided compelling arguments about blockchain benefits over traditional centralized databases, and talked religiously about our individual role in decentralizing the internet and building the future web.
Although neither one of us knew exactly how the blockchain works, we agreed that a certain blockchain is a database that contains immutable information about some stuff. For example, in the case of the Bitcoin blockchain, each copy of the blockchain has the entire history of all transactions since its initialization. Other blockchains can store information about content items and their owners, About cars and their registrations, or about almost anything.
Jeremy highlighted his major criticisms to using the blockchain in his context. First he said that if somebody wants to host their own content, they do not need a blockchain, and using a blockchain might involve risks of losing the content in some scenarios, like when losing the encryption keys. That was a real deal breaker in Jeremy’s context, most probably because he lost his YouTube archive, which made him conscious about this issue.
Jeremy stated that his goal is to own his content, which means that he wants to edit, update, and delete as he sees fit. A blockchain with immutable transactions is useful for storing financial transactions where nobody should edit or delete existing information. In Jeremy's context it makes no sense to lose flexibility for the sake of using a blockchain.
Finally, Jeremy said that when you host the entire blockchain, you will be hosting every transaction that any other user has made. It makes sense to do that if you are dealing with financial transactions, and you want to audit every transaction in the system. In Jeremy’s context, transactions mean publishing something and recording a trail on the blockchain. But in this context why would he care to verify what other people are publishing? This feature makes no sense in his context, and adds no value that he can benefit from.
Jim mentioned some gamification and speculation features in some leading blockchains. According to him, these features would be an extra income source. I agreed, and added that he can benefit from this income source until the day he gets purged, and although he might not lose his content, he risks losing all the extra benefits.
Marc wanted my thoughts about Odysee and BitChute, and I told him those sites are some of the best available. I added: "I have changed my habits to use them more than YouTube. However, from a content management perspective, Odysee is under a heavy lockdown, and does not care about conforming to standards, while BitChute is a bit relaxed." I added that "both sites are still way beyond YouTube in API and integration features, which is what I care about when building a strategy for content production."
Those sites are both new and comparing them to YouTube is unfair, so instead, I proposed to the group that we try to identify what criteria a certain social network should satisfy to support a successful content production strategy. We started brainstorming and agreed that if a content creator wants to own their content and host them, and to cooperate with a social network, while respecting the specific content and community features of the different networks, they should favor the networks that have the following features:
- The social network should have clear policies about what content is allowed on the network, and what processes are in place to handle content policy disputes.
- The social network should allow members to export their entire history, either via an API or via an export feature that produces a standard format like JSON or XML.
- The social network should allow posting new content via an API, and treat API posts like any post from the social network’s user interface.
- The social network should allow exporting the latest content of an account using an API call or a standard format like RSS.
- The social network should allow followers of an account to receive unrestricted updates or notifications about the account’s new content.
- The social network should have a policy to punish abusers who abuse a certain feature, not punish all users of that feature.
And for site management we added a important feature:
- The social network should allow embedding media content into other sites using the media’s unique identifier or using a standard protocol like oembed. Embedding hardcoded iframes might be good enough in the beginning but is not favorable on the long run.
While writing these requirements, we tried to respect the networks freedom to develop their content and user engagement features, and focused on what a site owner might need when integrating with a certain social network. Some of us wanted to add more requirements, and they did that for their own context. The list above is what the four of us agreed upon.
During the discussion, I wanted to add something like "I can influence the decisions of the administrators of the social network." I argued that if I have no influence on the social network, I am under total control by the administrators. That would be a lose-win agreement, and I am destined to lose. The other three argued that as long as you own your content, you can leave any social network when it becomes unuseful to you. I had to agree with them on that because it made more sense to me.
Next, each one had a task to evaluate and grade his social networks according to each one’s context. When we finish grading, we will post the results on The Unweb Developer blog. Meanwhile, feel free to share your own requirements and your grades in the comments below this article.
Al Saleh
The Unweb Developer
unweb.dev
Comments