To create a fully-functional, open-source, decentralized forum, inspired by Discourse and Reddit, that runs on the SAFE network. Anyone should be able to create their own discussion communities and participate in them without any technological expertise, and the project should serve as a good example to developers on how to build apps for the SAFE network.
At the time of this writing, the SAFE API has not been released, and a lot of the network's functionality has not yet been finalized. This does not mean that no work can be done to start writing apps for SAFE.
To create a forum / discussion community website that melds together Reddit/Discourse, with bare-bones functionality using a simple CRUD backend API that most closely immitates SAFE, such that the amount of work required to port the API to SAFE will be kept to a bare minimum. The more complexity introduced to the code, the more it will likely deviate from the SAFE API and require more work to port over, which is not the goal of this project. The idea is to, over time, make adjustments and additions to the forum as more-or-less-finalized details emerge about SAFE behavior and API. The more finalized details there are, the more complexity can be added to the application.
The MVP will have the following features, more or less in order of importance:
- Display list of all communities on main site page
- Allow any user to create his/her own community around any topic
- Display list of all threads within a community sorted by creation date. High priority to add more sort options later
- Allow moderator to de-reference threads (e.g. delete threads from collection)
- Users will post markdown-formatted threads and/or links/anchors to other URLs
- Display a thread and its posts, ordered by post creation date
- View/edit user profiles
- "Like" and "unlike" a post
- "Tip" the author of a post with safecoin. Display number of tips in post, and display tip count when clicked.
- Stickied threads, created by moderators
- Direct/private messaging between users
- Lots of indexes to allow viewing data in different ways (some examples below)
- Save "member count" of communities, sort communities in main page by number of members (perhaps number of unique posters)
- Sort threads by latest activity
- Nested posts/comments
- Sort posts/comments by: old, new, number of likes, safecoin tip total
- When posting links, fetch thumbnail of link
Firebase will be used as the backend API that will be used before SAFE is released. Firebase was chosen because, like the SAFE network:
- It acts as a NoSQL key/value store
- Data is stored using JSON at specified directories/locations
- App developers don't need to set up any servers or install specialized databases/software on them
- Authentication is built in
- It provides the methods by which CRUD permissions can be allocated for each user at each URI
- It's free/cheap to use
Although we know SAFE will provide a way for users to make CRUD operations only on permissable items, how these permissions will work is still a question. Mainly, who owns collections/indexes of data spanning multiple users, and how will these indexes be updated? Structured Data has been introduced in SAFE, but it is still unclear how they will be used. Thus, indexes/collections of objects will be kept to a bare minimum until there is more clarification.
Ownership and structure on Firebase will work in a way that will most closely resemble SAFE using the following directory structure:
* / (root)
* users
* $userid
* public
* private
In SAFE, /users/$userid will map to a software namespace within the user's own virtual drive, e.g. /safetalk. The user's public directory will be readable by anyone, and in some cases writeable by others (for collections), while their private directory will be used for personal private storage (their own thread bookmarks, for example). Again, whether it will be possible to write to others' drives on SAFE is questionable, and time will tell the correct way to go about indexes/collections.
As an example, a URI on Firebase would be /users/$userid/public/communities/$communityname.json, while on SAFE it would be something like this: /safetalk/public/communities/$communityname.json. Naturally the user id would not be required in the URI (this will be handled by SAFE's domains/DNS/etc.)
To keep the forum as decentralized as possible, objects will be owned by the users that created them. Child-collections will also be owned by them, but the objects they reference will be owned by their respective creator. Thus, a typical hierarchy will look like this, in terms of ownership:
- Admin - Owns the website, and collection of communities
- Moderator - Owns a community, and collection of threads
- User A - Owns a thread and collection of posts in the thread
- User B - Owns a post in the thread, and the collection of "likes" and "tips" for his post
- User C - Owns a "like"
This hierarchy means that data can only be de-referenced by the owner of a higher-level object, but never truly modified or deleted. Bogus data can be added to collections by the owner, such as fake "likes" on a post, but this can be easily offset by verifying the object exists on the like-owner's drive.
I anticipate that some sort of archiving mechanisms will be implemented where snapshots of collections will periodically be saved by other users so that a full history can be preserved in case of censorship or manipulation of collections. Perhaps this archiving can even be an optional built-in feature of the forum.
It will be trivial for anyone to regularly download/backup collections at any point in time. If an admin goes overboard with deleting communities, for example, a new website could easily be set up with a "snapshot" of communities in the past, and users could jump ship to another website without any loss of data. This will encourage admins to please the users.
The same can be said of a moderator in a community. It would be trivial for someone to copy a collection of threads and create another community based on the other. Essentially the two communities would overlap and be the same, but only the main thread list would differ. This would alleviate most of the censorship problems currently witnessed in many Reddit communities.
In Firebase, a new object can be added to a collection using the push() method, which automatically generates a unique ID for the object. For example, a collection could look like this:
{
"Jx5GJqWJ6ojch_8JYCK": {
"name": "Bob Smith",
"username": "bobsmith"
},
"Jx5GPaLm3IB6wSCBsVb": {
"name": "John Smith",
"username": "johnsmith"
}
}Pushing a new object would simply extend this JSON object.
One could GET the whole collection at the uri /collection, and GET a specific item at /collection/Jx5GJqWJ6ojch_8JYCK.
In SAFE we will do something similar: have a directory /collection, in which we will place individual JSON files. The name of the json file will be the unique id, which will be generated client-side, and the file will contain the object. Using the above example, we would have the file /collection/Jx5GJqWJ6ojch_8JYCK.json which would contain:
{
"name": "Bob Smith",
"username": "bobsmith"
}If we wanted the entire collection, we would request the entire /collection container, or a subset of it using the SAFE API.
The difference between accessing collections/files in Firebase and SAFE are minor, and it should be relatively easy to switch between the two.
Decentralizing data ownership introduces a new problem concerning versioning. In conventional application with SQL databases, when the application's requirements change, it is trivial to issue an update to entire tables of data, mutating them as necessary. This will not be possible on SAFE. A mechanism will need to be in place that allows all application updates to be backwards-compatible with existing data.
I propose the following solution:
- Hard-code the current version of the application into the source code
- Include the version number of the software used into each and every object created.
- When fetching data from the network, filter it through utility classes that know how to reduce data from each software version, in a way that the latest software version can understand.
Question: should software versions be included in collections also?
One killer feature that would further fight censorship is to eventually make most or all collections read- and append-only. This would mean that even moderators and admins cannot dereference data. This would call for two minimum requirements:
First, data must be stored in no-mans-land, in no one's personal drive, and thus it cannot be deleted by anyone. Only new collection objects would be added.
Secondly and most importantly, since this could encourage spam and illegal content, members of the community would need to pitch in to vote on collection objects. Objects below a voting threshold would not be displayed. Voting is not an easy feat in decentralized applications, as it could be easily gamed. There are discussions on the MaidSafe forums on how voting could be done using SAFE. Naturally this is a topic that encompasses nearly all online communities, not just SAFE Talk, so this will likely be a solution that needs to be built into SAFE. For example, an API endpoint that allows casting votes on any object, using its own algorithm on determining trustworthy users/nodes, perhaps using vault rankings or other measures.