User privacy, distributed API and other thoughts about data access

[d47081]

Yggdrasil allows to create innovative authorization model for social webapps - without login, passwords, emails, authorization gateways and other classical solutions - just identify user instantly by IPv6 or public key.

YGGtracker uses yggdrasil IP as user identify to build magnets ownership, comments, stars and other features.

Visual profile / content author detection could be implemented by identicons, that allows easily remember specified profile, like favicon for website opened in tab.
Optionally, member can provide some local username, just doubts this not a past and useful in distributed profile model. Extra-features like this maybe out of simple and native understanding, makes new layers...

Even ideas of social services could be infinitive, the fact, YGGtracker is a first social prototype in YGGverse, and this app birth the ideas about distributed data exchange also, to make registry accessible and resistant of nodes down.

The main doubts in context:

• Protocol - according to Activity pub or some else of actual this moment
• The privacy - even yggdrasil not oriented to this subject, like DHT at all without third-party solutions, the basement model of ethics is let user know how data stored will be processed by service.

In distributed API context, a question - how to ethically organize data access level between different nodes. In one case, nice think is to make profile settings, where each user can setup which exactly the data could this resource share data to others.

On YGGtracker example, we have implemented identicons using popular jdenticon library, that could be shared / displayed, but still disabled, because of few ways: keep user 'hidden' by generating icon with unique internal userId or make it commonly accessible - by selected library and public key / IPv6.

In my opinion, for example, service providers able to implement profile options: icon provider, icon identity field, content to share, where disabled by default, until user enable it.

I think, in UI or API, we can't make public profile ID related to yggdrasil node address or pubkey, because even hashed, could be simply detected using network crawlers or public registries (and algorithm that presented in sources) Solution - local userId field only by default, until changed by user. Just another services will not be able to identify this user as a part of global yggdrasil ecosystem.

Please share your thoughts and help us to build some new alternative to the classical web!

[d47081]

To make database distributed with other YGGtracker nodes, we can identify unique magnets by it timezone-independent timeAdded field (that presented in unixtime) and update the changes everywhere by larger timeUpdated value of available.

The chance that few nodes getting new content on same timestamp is pretty low but not gives 100% guaranty.

And about cross-site edition possibility without user IPv6 sharing - passkey field on settings page, where user able to sign own content by password_hash so all the magnets identified by unixtime will contain PASSWORD_BCRYPT transmitting to other nodes, where user can edit own content later and everywhere.

So even where resolve content and ownership sharing by keeping user privacy, some social features like stars, comments, downloads, views requires solution too. By using content signs as user identify marker we increase the server load that could be issue with database grow. This project positioned as JS-less, so client side computing solutions maybe not an option.

Question of trust to other nodes maybe should be based on some whitelist, presented in separated json config, beside trackers.json where each node can change this default list or provide the meta markers of content subjects to download.

[d47081]

Probably, best solution is maybe to ask each user for choice.

By this implementation, YGGtracker able to process content by different ways - for public and local users.

Also, welcome message implements agreement feature, so now we can make new steps to build decentralized app and keep user data in safety by default.

[d47081]

#14
#16