On this part, let's get into the technical details of the new type of social network.
User handling
At first, look at a sample profile content contained in an XML file named nsn_p-profile.xml which is hosted on the user's "user space", please see below.
Therefore we assume a first social network user who has a rather normal attitude towards privacy and who likes to get in contact to other users with similar interests via this social network. So he decides his profile and primary personal data to be published on the central directory/directories he has chosen. This is technically represented by the XML entry <upkey pub="true"> meaning that the user profile acces key is published on central directories, and later on commonly by pub="true" within other tags related to personal information. Additionally, he allows profile visitors to access personal information which is not published on central directories: <uikey1 pub="true"> means that the profile visitor gets access to information declared as "privacy level 1" (prlev="1"). Users who want to get access to information covered by higher privacy levels on this profile have to make their GUI ask the profile owner's user script for the corresponding key.
The full XML file nsn_p-profile.xml looks like this:
<?xml version="1.0"?>
<NSN_pprofile><!-- pprofile = "personal profile" -->
<NSNuserprofiles><!-- this level only for compatible XML structure depth -->
<userprofile pub="true">
<handle>24c9e15e52afc47c225b757e7bee1f9d</handle>
<!-- md5 of "user1" - only if interested -->
<upath>joemiller.tld/@nsn@/profile/joemiller01/connect.xml</upath>
<upkey pub="true">9876543210fedcba9876543210fedcba</upkey><!-- "upkey": user profile access key -->
<uikey1 pub="true">43210fedcba9876543210fedcba98765</uikey1><!-- uikey1 pub="true" perhaps is useful when items with prlev="1" only should not appear in central lists but may be visible to profile visitors. All this becomes rather obsolete if a search engine gets access to the NSN! -->
<uikey2 pub="false">edcba9876543210fedcba9876543210f</uikey2>
<uikey3 pub="false">dcba9876543210fedcba9876543210fe</uikey3>
<!-- "uikey"s: user defined interaction/activity keys: users can define which rights they want do deliver on privacy level "uikey1", "uikey2", "uikey3" -->
<updata>
<!-- place for published / NSN-indexable info -->
<unick pub="true">Little Joey</unick>
<uname pub="true">Joe Miller</uname>
<avatar pub="true">myavatar002.png</avatar><!-- path to avatars should be listed in "upath" XML file -->
<keywords pub="true">networker;coder;biker</keywords>
<ucinfo>
<birthdate pub="false" prlev="2">1960-12-31</birthdate>
<address pub="false" prlev="2" format="nsn-full">;;Texas City;Main Street;99</address>
<econtact>
<email pub="false" prlev="2" use="true">biker@coding.us</email>
<email pub="false" prlev="2">joey1960goldwing@gmail.com</email>
</econtact>
<hobbies pub="true">social networks;PHP;Honda</hobbies>
<memberships pub="true">Goldwing Club Texas</memberships>
<webprofiles>
<webprofile pub="false" prlev="2">
<wphost>trumpy</wphost>
<wpaddr>https://trumpy.tld/user/newsfaker</wpaddr>
</webprofile>
<webprofile pub="false" prlev="2">
<wphost>spammy</wphost>
<wpaddr>http://spammy.tld/mymlmbusiness1960</wpaddr>
</webprofile>
</webprofiles>
</ucinfo>
<udinfo>
<!-- user defined profile info sets - the full (original) list should be a seperate XML file on the user's space for being easily shareable -->
<i0001 pub="false" prlev="3"><!-- prlev = "privacy level", refering to "uikey"s -->
<udiname>profession</udiname>
<udicont>postman</udicont>
</i0001>
<i0002 pub="false" prlev="1">
<udiname>high school</udiname>
<udicont>school of life</udicont>
</i0002>
<i0003 pub="false" prlev="2">
<udiname>religion</udiname>
<udicont>Flying Spaghetti Monster</udicont>
</i0003>
<i0004 pub="true">
<udiname>eat</udiname>
<udicont>burger;chocolate;coke</udicont>
</i0004>
<i0005 pub="false" prlev="2">
<udiname>something1</udiname>
<udicont><!-- ... --></udicont>
</i0005>
<i0006 pub="false" prlev="2">
<udiname>something2</udiname>
<udicont><!-- ... --></udicont>
</i0006>
<i0007 pub="true">
<udiname>workshop</udiname>
<udicont>milling machine;lathe;chainsaw</udicont>
</i0007>
<i0008 pub="false" prlev="2">
<udiname>something3</udiname>
<udicont><!-- ... --></udicont>
</i0008>
</udinfo>
</updata>
</userprofile>
</NSNuserprofiles>
</NSN_pprofile>
<upath>joemiller.tld/@nsn@/profile/joemiller01/connect.xml</upath> delivers all information for contacting this "user space" for the first time.
When this user chooses a centralized user directory to use / to enter, his profile data which are not tagged as pub="false" are sent to this list.
The centralized user directory sample below only contains two users. The second one has his "user space" hosted by a provider instead of on his own webspace, and he likes privacy very much ;-)
The full user directory e.g. is a centrally hosted XML file nsn_c-userlist.xml and it looks like this (shortened sample):
<?xml version="1.0"?>
<NSN_cuserlist><!-- cuserlist = "common or central user list" -->
<NSNuserprofiles>
<userprofile blocked="false">
<handle>24c9e15e52afc47c225b757e7bee1f9d</handle>
<!-- md5 of "user1" - only if interested -->
<upath>joemiller.tld/@nsn@/profile/joemiller01/connect.xml</upath>
<upkey>9876543210fedcba9876543210fedcba</upkey>
<uikey1>43210fedcba9876543210fedcba98765</uikey1>
<uikey2></uikey2>
<uikey3></uikey3>
<!-- user defined interaction/activity keys: users can define which rights they want do deliver on trust level "uikey1", "uikey2", "uikey3" -->
<updata>
<!-- place for published / NSN-indexable info -->
<unick>Little Joey</unick>
<uname>Joe Miller</uname>
<keywords>networker;coder;biker</keywords>
<ucinfo>
<hobbies>social networks;PHP;Honda</hobbies>
<memberships>Goldwing Club Texas</memberships>
</ucinfo>
<udinfo>
<!-- user defined profile info sets - the full (original) list should be a seperate XML file on the user's space for being easily shareable -->
<i0004>
<udiname>eat</udiname>
<udicont>burger;chocolate;coke</udicont>
</i0004>
<i0007>
<udiname>workshop</udiname>
<udicont>milling machine;lathe;chainsaw</udicont>
</i0007>
</udinfo>
</updata>
</userprofile>
<userprofile blocked="false">
<handle>7e58d63b60197ceb55a1c487989a3720</handle>
<!-- md5 of "user2" - only if interested -->
<upath>nsn-space.tld/users/ben_johnson_2/connect.xml</upath>
<!-- very private user - no forther data published, possibly many more on his profile -->
<updata>
<!-- place for published / NSN-indexable info -->
<unick>Benny</unick>
</updata>
</userprofile>
</NSNuserprofiles>
</NSN_cuserlist>
<userprofile blocked="false"> means that on this user directory, this user is not blocked. (The owner of the directory should be able to block inappropriate users.) Of course when cloning this directory, however the owner of the cloned instance can unblock the user on his instance.
When a user finds another user in the centralized user directory (or via another way) and successsfully connects to this other user, the second user's profile data are requested and stored on the first user's "user space".
The relating XML file nsn_p-userlist.xml looks like this:
<?xml version="1.0"?>
<NSN_puserlist><!-- puserlist = "personal user list" -->
<NSNuserprofiles>
<userprofile>
<handle>7e58d63b60197ceb55a1c487989a3720</handle>
<!-- md5 of "user2" - only if interested -->
<upath>nsn-space.tld/users/ben_johnson_2/connect.xml</upath>
<upkey>fedcba9876543210fedcba9876543210</upkey><!-- "upkey": user profile access key, received from this user -->
<uikey1>edcba9876543210fedcba9876543210f</uikey1><!-- "uikey"s: user defined interaction/activity keys, received from this user -->
<uikey2>dcba9876543210fedcba9876543210fe</uikey2>
<updata>
<!-- user defined amount of locally stored info? -->
<unick>Benny</unick>
<uname>Ben Johnson</uname><!-- received from this user -->
<keywords>privacy;privat life;family manager</keywords><!-- received from this user -->
</updata>
</userprofile>
</NSNuserprofiles>
</NSN_puserlist>
The comments within the XML file should be self-explanatory.
Content handling
Within this type of social network, any content is owned and permanently controlled by its author but nobody else. So the content itself is received and sent by the user script which is located on the user's "user space". The type and format of content is to be treated seperately from this article. (For an MVP, it should be acceptable to choose only plain text, HTML or especially Markdown, perhaps the best and most flexible alternative.)
So the only thing to be explained for now is the way of refering to user content.
As a preamble which possibly may be changed later on, we assume that any "content collection" (to be exact: content referral collection) also has an owner represented by a user, not by a hoster of a centralized directory.
Let's look at a discussion group for example. Other "content collections" even like personal messages etc. can have similar structurers then.
The following discussion group and its relating XML file is owned by our first user "Joe Miller".
The XML file nsn_u-linklist.xml looks like this:
<?xml version="1.0"?>
<NSN_ulinklist><!-- ulinklist = "user-hosted content link list" -->
<NSNdiskgroups>
<diskgroup pub="true">
<handle>513772ee53011ad9f4dc374b2d34d0e9</handle>
<!-- md5 of "group1" - only if interested -->
<dgpath>joemiller.tld/@nsn@/groups/codingbikers/connect.xml</dgpath>
<!-- joemiller.tld is "me" -->
<dgpassread pub="true">90a39a23bd76385f8e89eef6b5e7e04f</dgpassread>
<!-- md5 of "passwordread" - only if interested -->
<dgpasswrite pub="false">97ca536a9caa41472e524a2ec08a3633</dgpasswrite>
<!-- md5 of "passwordwrite" - only if interested -->
<!-- password for write access not published, users must ask the group owner. -->
<dgdata pub="true">
<!-- place for published / NSN-indexable info -->
<dgname>Coding Bikers</dgname>
<dgkeywords>networking;coding;biking</dgkeywords>
<dgdesc>This group aims to connect Bikers who also do coding.\nFeel free to join us!</dgdesc>
<dglogo>grouplogo2.png</dglogo><!-- path (folder) defined in connect.xml -->
</dgdata>
<disksubgroup pub="false"><!-- not published, else this subgroup would appear in the (central) c-linklist -->
<handle>13772ee53011ad9f4dc374b2d34d0e95</handle>
<dgpassread pub="false">0a39a23bd76385f8e89eef6b5e7e04f9</dgpassread>
<dgpasswrite pub="false">7ca536a9caa41472e524a2ec08a36339</dgpasswrite>
<dsgtitle>Welcome Thread</dsgtitle>
</disksubgroup>
<disksubgroup pub="false">
<handle>3772ee53011ad9f4dc374b2d34d0e951</handle>
<dgpassread pub="false">a39a23bd76385f8e89eef6b5e7e04f90</dgpassread>
<dgpasswrite pub="false">ca536a9caa41472e524a2ec08a363397</dgpasswrite>
<dsgtitle>Tell us about your rides</dsgtitle>
</disksubgroup>
<disksubgroup pub="false">
<handle>772ee53011ad9f4dc374b2d34d0e9513</handle>
<dgpassread pub="false">39a23bd76385f8e89eef6b5e7e04f90a</dgpassread>
<dgpasswrite pub="false">a536a9caa41472e524a2ec08a363397c</dgpasswrite>
<dsgtitle>Tell us about your projects</dsgtitle>
</disksubgroup>
</diskgroup>
</NSNdiskgroups>
<NSNchatgroups>
</NSNchatgroups>
</NSN_ulinklist>
A discussion group is protected by passwords for reading and for writing. If the group e.g. is wanted to be readable for any user, the password for reading can be published on a centralized content directory.
When the owner of this discsussion group chooses a centralized content directory to use / to enter, the group data which are not tagged as pub="false" are sent to this list.
Lists of group members and of group contents each have the same owner as the above sample file and can be structured similar to centrally hosted directories.
So the following discussion group member and content list XML file is also owned by our first user "Joe Miller".
The XML file nsn_u-comp_group.xml looks like this:
<?xml version="1.0"?>
<NSN_ucomp_group>
<NSNgroupprops><!-- or omit this part and name this file by the following handle entry -->
<diskgroup>
<handle>513772ee53011ad9f4dc374b2d34d0e9</handle>
<!-- md5 of "group1" - only if interested -->
<dgpath>joemiller.tld/@nsn@/groups/codingbikers/connect.xml</dgpath><!-- not really necessary(?) - see "nsn_u-linklist.xml", unique handle on the same user space is sufficient -->
</diskgroup>
</NSNgroupprops>
<NSNgroupmembers>
<groupmember>
<handle>7e58d63b60197ceb55a1c487989a3720</handle>
<!-- md5 of "member1" - only if interested -->
<upath>nsn-space.tld/users/ben_johnson_2/connect.xml</upath>
<disksubgroup>
<handle>13772ee53011ad9f4dc374b2d34d0e95</handle>
<dgpassread>01234567890abcdef01234567890abcdef</dgpassread>
<dgpasswrite>abcdef01234567890abcdef01234567890</dgpasswrite>
</disksubgroup>
<disksubgroup>
<handle>3772ee53011ad9f4dc374b2d34d0e951</handle>
<dgpassread>1234567890abcdef01234567890abcdef0</dgpassread>
<dgpasswrite>bcdef01234567890abcdef01234567890a</dgpasswrite>
</disksubgroup>
<disksubgroup>
<handle>772ee53011ad9f4dc374b2d34d0e9513</handle>
<dgpassread>234567890abcdef01234567890abcdef01</dgpassread>
<dgpasswrite>cdef01234567890abcdef01234567890ab</dgpasswrite>
</disksubgroup>
</groupmember>
</NSNgroupmembers>
<NSNgroupentries>
<diskgroup>
<disksubgroup>
<handle>13772ee53011ad9f4dc374b2d34d0e95</handle>
<entries>
<entry>
<conthash time="1588440943">a22c5602786e1cec221ae7d31f661303</conthash>
<!-- md5 of "This is content" - only if interested -->
<contpath>nsn-space.tld/users/ben_johnson_2/content/getcontent.php?comp=groupentry&contentid=1000987&groupownerid=100000645&handle=13772ee53011ad9f4dc374b2d34d0e95&key={exchangekey}</contpath>
</entry>
<entry>
<conthash time="1588447453">3f2660a91deba04caf9ad8b53e8a4d6d</conthash>
<!-- md5 of "This also is connnntent" - only if interested -->
<conthash time="1588447494">c68b291e3d834181b80621012de0d514</conthash>
<!-- md5 of "This also is content" - only if interested -->
<contpath>nsn-space.tld/users/ben_johnson_2/content/getcontent.php?comp=groupentry&contentid=1000984&groupownerid=100000645&handle=13772ee53011ad9f4dc374b2d34d0e95&key={exchangekey}</contpath>
</entry>
</entries>
</disksubgroup>
<disksubgroup>
<handle>3772ee53011ad9f4dc374b2d34d0e951</handle>
<entries>
<entry>
<conthash>...</conthash>
<contpath>...</contpath>
</entry>
<entry>
<conthash>...</conthash>
<contpath>...</contpath>
</entry>
<entry>
<conthash>...</conthash>
<contpath>...</contpath>
</entry>
</entries>
</disksubgroup>
<disksubgroup>
<handle>772ee53011ad9f4dc374b2d34d0e9513</handle>
<entries>
<entry>
<conthash>...</conthash>
<contpath>...</contpath>
</entry>
<entry>
<conthash>...</conthash>
<contpath>...</contpath>
</entry>
<entry>
<conthash>...</conthash>
<contpath>...</contpath>
</entry>
</entries>
</disksubgroup>
</diskgroup>
</NSNgroupentries>
</NSN_ucomp_group>
Each user has his own passwords for reading and writing, so each user can be excluded alone when needed.
The content hash <conthash time="1588447453"> including a time stamp allows users to see if and when content (which always is owned and controlled by the contributing user) has been changed intermediately.
The full content directory e.g. is a centrally hosted XML file nsn_c-linklist.xml and it looks like this (sample with only two discussion groups):
<?xml version="1.0"?>
<NSN_clinklist><!-- clinklist = "common or central link list" -->
<NSNdiskgroups>
<diskgroup blocked="false">
<handle>513772ee53011ad9f4dc374b2d34d0e9</handle>
<!-- md5 of "group1" - only if interested -->
<dgpath>joemiller.tld/@nsn@/groups/codingbikers/connect.xml</dgpath>
<dgpassread>90a39a23bd76385f8e89eef6b5e7e04f</dgpassread>
<!-- md5 of "passwordread" - only if interested -->
<dgpasswrite></dgpasswrite>
<!-- no password for write access published, users must ask the group owner. -->
<dgdata>
<!-- place for published / NSN-indexable info -->
<dgname>Coding Bikers</dgname>
<dgkeywords>networking;coding;biking</dgkeywords>
<dgdesc>This group aims to connect Bikers who also do coding.\nFeel free to join us!</dgdesc>
</dgdata>
</diskgroup>
<diskgroup blocked="false">
<handle>f617868bd8c41043dc4bebc7952c7024</handle>
<!-- md5 of "group2" - only if interested -->
<dgpath>secretnet.tld/nsn-clubs/group234/connect.xml</dgpath>
<dgpassread></dgpassread>
<!-- no password for read access published, users must ask the group owner. -->
<dgpasswrite></dgpasswrite>
<!-- no password for write access published, users must ask the group owner. -->
<dgdata>
<!-- place for published / NSN-indexable info - nothing published -->
</dgdata>
</diskgroup>
</NSNdiskgroups>
</NSN_clinklist>
The comments within the XML file should be self-explanatory.
When a user finds a discussion group in the centralized content directory (or via another way) and successfully accesses this group (here by receiving passwords for reading and writing and by receiving information about subgroups etc.), the group data are requested and stored on the user's "user space".
Assuming the user is only participating in one discussion group, the relating XML file nsn_p-linklist.xml (which is hosted on the user's "user space") looks like this:
<?xml version="1.0"?>
<NSN_plinklist><!-- plinklist = "personal link list" -->
<NSNdiskgroups>
<diskgroup>
<handle>f617868bd8c41043dc4bebc7952c7024</handle>
<!-- md5 of "group2" - only if interested -->
<dgpath>secretnet.tld/nsn-clubs/group234/connect.xml</dgpath>
<dgpassread>01234567890abcdef01234567890abcdef</dgpassread>
<!-- password received for read access -->
<dgpasswrite>abcdef01234567890abcdef01234567890</dgpasswrite>
<!-- password received for write access -->
<dgdata>
<dgname>Privacy Protection</dgname>
<dgkeywords>privacy;security</dgkeywords>
<dgdesc>A group for people involved with privacy related tasks</dgdesc>
</dgdata>
<disksubgroup>
<handle>617868bd8c41043dc4bebc7952c7024f</handle>
<dgpassread>1234567890abcdef01234567890abcdef0</dgpassread>
<dgpasswrite>234567890abcdef01234567890abcdef01</dgpasswrite>
</disksubgroup>
</diskgroup>
</NSNdiskgroups>
<NSNchatgroups>
</NSNchatgroups>
</NSN_plinklist>
The comments within the XML file should be self-explanatory.
Further use of XML
Some more use of XML files can be such as main network settings (as a standard over the whole network, which should be well chosen as otherwise it could exclude members of other networks of the same type), user's personal preferences hosted on the user's "user space", etc.
Even user content itself may be stored in XML files as far as this seems useful instead of e.g. using single files for each content unit.
However, using XML is just one of many options, but it seems to me to be a very useful one for starting an MVP and perhaps also later on.
How to continue?
Sorry about this something "dry" part of the (elsewhere) rather visionary concept.
I hope it helps to get a little bit closer to the point of starting coding!
As my concept on the technical side mainly has to supply the description of interface points between different component types, I think a nice amount of work on this concept is already done. If this idea starts spreading, the components themselves will be optimized on and on, so we do not need to start with the perfect solution. Details concerning content formats etc. do not need to be conclusively declared from the beginning. And as the main portal script/plugin/app only has few interface conditions and is mostly unlimited in design, there is not much that has to be declared about it now.
This is the 3rd part of the concept. At this moment I hope that after the 4th part of this concept, one can start coding - with lots of creativity and liking to meet own decisions ;-)
Like to contribute?
If you like to contribute to this visionary new standard for social networks, I would be glad to receive your following request!
Top comments (0)