Before thinking of a detailed technical solution, there are some principal details to be declared.
As this new social network should offer the opportunity to be used in many different manners (business network, typical social network, discussion forum, messenger etc. or of course various combinations of these), its functionality should be configurable in a widely variable manner. For this, each option of content type could/should be represented by an easily integrable plugin (within the portal script) for handling it and a standard for plugins should be implemented straight from the beginning, at least after building a first MVP.
And if possible, the minimum set of user hosted implementation, which is the user hosted content exchange interface, should not need to be extended on grounds of this variability later on, so it should be enough flexible to handle all types of content. This means that all possible types of content should be standardized as far as possible.
Does an originally built MVP already have to meet these requirements? Yes and no - I think it should have a structure which enables this when scaling up later on, but that's all.
The full requirements seem to be rather huge, but a first MVP in my opinion will only have to show that this new type of social network offers good accessibility, allows healthy competition between user space providers and (later on) between script suppliers and therefore has the potential of really becoming a new standard for social networks and to be attractive for adopters like web hosters, email providers, etc.
For this, a rather small version of MVP should be sufficient at first. So I hope at least.
Let's define the technical basics!
For a first start, I personally recommend using very basic standards to allow users of free web hosters to participate and to allow possibly many contributors to enter. And if this type of network really should becomme a new standard, it will be helfpul if it causes possibly low server load.
So I really would like to avoid using databases like MySQL but have the data stored in flat files.
I would like PHP being used as the basic programming language und - as far as I can see today - I would prefer no backend framework, at least for the user implemented scripts which are the main base of the applicable standard.
For data structures like directories and user owned referral tables, I would prefer XML format to be used at least for the MVP, ideally also later on. This enables using OOP very easily as there are enough basic commands for XML handling in PHP OOP already.
But this does not all have to be the same for all participants, as after the start there will be competition on all levels soon, and only the interaction has to be standardized at the end.
To me, it is important to have a lightweight MVP at the beginning and to do nothing that prevents the social network components from staying lightweight on the long term.
There are several things I'd like being mentioned before starting together. Please don't beat me for this somewhat unstructured listing below ;-)
One thing about security:
As user content is decentrally hosted and comes from different web addresses, we must make sure that exchanging this content is wanted by both sides. For example, a discussion group entry request is sent by the committing user(script) together with his/its web address, then the quasi-central directory host sends a one-way-encrypted key of this request and one additional new key back to the user(script) to check if the request really came from him/it, and then the the user(script) sends the original request again and also a one-way-encrypted key of the additional key he/it receieved.
Or we use a pair of encryption keys like used in HTTPS, but this is nothing I am familiar with, so I would have to rely on others at this point.
One thing about checking actuality and originality of user committed contents:
When a user commits his contents to discussion groups, in PMs, etc., it will still be content he has control of. This is a main aim of this type of network which gives many advantages to it as described earlier.
Nevertheless, other users such as discussion group members, receivers of PM, etc. should be able to see if these contents have been changed after transmitting for the first time. So even if we should not save clones of content mostly, we should save something that lets us recognize changes. This can be hashes of submitted contents. Whenever content is committed, its hash should be saved on the receiver side. Whenever content is changed afterwards, it so can be marked as "deprecated" on the receiver side portal even if the new content is displayed.
One thing about interoperability:
I can not be absoutely exact in this point, but some time ago, I read about the decentralized social network "Mastodon" that is said to be far superior to the decentralized social network "Diaspora" concerning user acceptance and therefore also concerning spreading speed because it offers many interface options with several open source media formats/platforms. I think this is an important aspect we should keep in mind and which can help us to also spread our idea to many former Mastodon users. Perhaps they like using both types of network, or they even start integrating one network with the other?
How starting together?
For starting together, there is one main question:
What components have to be defined to let contributors enter with possibly independent commits?
I think it's possible to have only basic XML tables like directories, user owned content structure tables, user profile infos, user preference settings and so on for starting together. And - a first definition of the interface request for exchanging contents. Nearly everything else can be built modularly following the intention of the contributors and, of course, the main concept here.
Most of the rest can be explained looking at sample XML referal tables. Other things can early be left to the decision of the contributors.
Within the next step, let's have a look at such sample XML tables...
Top comments (0)