twtxt vs Org Social: the evolution of an idea
twtxt was one of the strongest inspirations behind Org Social: a plain text file served over HTTP, with no active server, no database, no signup. I personally admire the work done by Buckket: the concept is so powerful that it has captured the hearts of many people over the years. Its author gave us an elegant solution for creating a personal microblog, an alternative to Twitter (now X).
That said, Org Social would not exist if it weren't for the limitations of twtxt or the natural evolution of social networks. Org Social keeps its spirit, learns from its mistakes and from the competition, reinforces other concepts (like federation) and adopts modern features (like visibility). It is not an improvement, it is a shift in approach.
That's why I'd like to go over the three most important aspects where Org Social improves on twtxt.
Technical improvement
The most obvious one is the ability to have structured metadata thanks to Org Mode.
#+TITLE: Bob's journal
#+NICK: Bob
#+DESCRIPTION: I'm a software developer and I love open source.
#+AVATAR: https://my-awesome-website.com/avatar.jpg
#+LINK: https://my-awesome-website.com
#+FOLLOW: https://foo.org/social.org
#+FOLLOW: https://jane.com/social.org
* Posts
** 2024-12-12T12:00:00+0100
:PROPERTIES:
:LANG: en
:TAGS: emacs org-social
:CLIENT: org-social.el
:VISIBILITY: public
:MOOD: 😊
:END:
Hello Org Social!
This opens the door to giving context to each post, having native threads, tagging, organizing in groups, defining visibility, running polls...
| Feature | twtxt | Org Social |
|---|---|---|
| Format | plain text (Markdown optional) | Org Mode |
| Mentions | yes | yes |
| Profile metadata | minimal | rich |
| Tags | #hashtag inside the body |
:TAGS: as metadata |
| Native threads | no | REPLY_TO |
| Multiline | no | yes |
| Sub-headers | no | yes (#+) |
| Federated groups | no | yes (GROUP) |
| Languages | no | yes (LANGUAGE) |
| Polls | no | yes |
| Reactions / boosts | no | yes |
| Visibility | no | VISIBILITY (though not fully private) |
| Account migration | no | MIGRATION |
We don't just get richer post bodies: the possibilities for interaction between users grow without limit. The specification invites you to create, not to work around limitations.
5 design principles
Any new social network specification should follow these principles:
- Simplicity: the format must be easy to understand and write with any text editor, with no special tools or advanced technical skills required.
- Accessibility: the feed must be readable by both humans and machines.
- Decentralization: every user should be a node, a self-hosted feed or one publicly accessible.
- Org philosophy: the format must take advantage of Org Mode features, like links, tables, code blocks, checkbox lists, etc.
- Your information belongs to you: no one owns your feed, content, or followers. Just you and your text file. Where you host it is a separate matter.
Without clear rules, the ecosystem fragments. There isn't a single line of the specification that isn't aligned with the points above.
Infrastructure should add value, not be a requirement
A very important element in Org Social are the Relays, which let you organize threads, discover other users, receive notifications, run searches, get an RSS feed, etc. However, without them the network would still work: users could keep publishing, following others and interacting. Relays are not the core of the social network. Clients can rely on them, but should never depend on them. This isn't a quality exclusive to Org Social: twtxt is also aligned with this principle. The point lies elsewhere.
The goal of clients is to make reading and writing feeds (social.org) easier, not to be a requirement to participate. That said, they are very practical for building your timeline, since you need to read and sort the feeds of the users you follow. For that there are Desktop and Android versions thanks to Emacs, plus a native iOS version written in Swift.
The differentiating point is balancing different user profiles via the infrastructure. For example:
- Users with no technical knowledge: in a couple of clicks you can have an account thanks to Org Social's free hosting. The clients will take care of syncing and publishing for you. It is very similar to how other networks like Mastodon work, except that everything lives in a plain text file locally and transparently.
- Users with some technical knowledge: they can host their
social.orgon GitHub, GitLab, their own server, etc. They control and manage where it is hosted and how it connects. - Users with deep technical knowledge: they fully control their presence on the network. They run their own server (with WebDAV, for example), with their own configured domain, with their own caching policies... or they even spin up their own Relay for extra speed or to build private federations.
It embraces every kind of user, without sacrificing the essence of the social network. You don't need to be an expert to take part, but if you are one, you control every byte.
Conclusion
Org Social doesn't just improve on twtxt technically: it also evolves the concept of a social network on top of plain text. It takes a step forward by providing more infrastructure and incorporating modern features.
The future is not about going massive or competing with Mastodon, but about satisfying a very small niche of users.
Focus on the content or on engaging with others, Org Social will take care of the rest.
- Technical improvement
- 5 design principles
- Infrastructure should add value, not be a requirement
- Conclusion
This work is under a Attribution-NonCommercial-NoDerivatives 4.0 International license.
Support me on Ko-fi
Comments
There are no comments yet.