metadat: this is a special behind-the-scenes dat that holds metadata about a user, device, listing of dats, or any user-to-user communication
public metadat: this is a metadat that holds a public listing of dats for a user, plus the user's pgp public key
relationship metadat: this is a metadat that holds relationship metadata for two users (eg, what private dats are shared between them)
public dat collections
In order to find and follow cool public metadats (eg "NPR's dats""), simply enter a public metadat address. With a UI, that address could have a clickable link.
following someone
To follow someone, you enter the address of their metadat, which gets saved locally/privately. Then all their public dats can be listed.
adding a contact
Adding a contact allows you to give them private access to certain dats. To create this relationship, both contacts need to initiate a contact request with the other.
On the creation of a new contact requset, a new dat gets generated that will hold the relationship metadata ("relationship metadat"). Once one contact initiates the contact request, that relationship metadat address gets encrypted using the other contact's public key and placed in their public metadat. Once both contacts read each other's relationship metadat addresses from each other's public metadats, then that encrypted address can be immediately deleted from their public metadats.
For each contact, two relationship metadats should be saved, one that contact A writes to and contact B reads from, and the other for contact B to write to and contact A to read from.
Once both relationship metadats are established, then contact A can start privately sharing dats with contact B, and vice versa.
setting permissions on dats
When you create or edit a dat, you can explicitly set which among your contacts have access to that dat. For each contact that you give access, the dat address will get saved into the relationship metadat that you have for each contact. If you make the dat public, then the dat address simply gets listed in your public metadat instead.
user groups
When you set permissions on a dat, it might be handy to give access to a whole group of contacts all at once, without having to select individually.
After a contact is established, you can simply put a group label within the relationship metadat. Each contact could request to be in a group from the other contact. When you set permission on a dat, you can select groups as well as individual contacts.
cross-device pairing
Similar to creating a regular contact, you create a fully-trusted relationship between two devices. Any private dat address on one device would be immediately put in the "relationship dat" and listed and downloadable on the paired device (eg your laptop and your phone). This could be thought of as a kind of "full-trust device network". For each dat you create on any device, you could choose which other devices in your trust network should auto-download the full dat.
local privacy and encryption
Since everything is based around PGP keys, we could encrypt all metadata in all metadats. Even though the dats themselves are private, and are shared over SSL, if your device was stolen, then someone could find all your metadat information. Encrypting everything locally would ensure that simply stealing the device wouldn't expose all your dat addresses. All dat addresses that are shared with other contacts are encrypted using their pubkey.
messaging
Could have some simple device-to-device messaging by placing a pgp-encrypted message in your relationship metadat for someone else using their pubkey.
"forking" UI
If you download a dat and want to edit it, there could be a simple method for initializing a new dat with the edits and notifying the initial dat creator of your edited dat address, kind of like a fork.
data rendering
Say you have a dat with files in a certain format (.csv, .md, etc). When you click the file, you could choose a "renderer" for that file. The renderer could be a JS/HTML application that takes the file as input . You could simply provide the .git url of the renderer app when opening the file (and in a UI, the "renderers" would be pre-listed). This would open up potential to build open-source renderers for spreadsheets, wiki data, etc. The renderer itself does not need to be part of the dat, and can just be pulled off github or similar.
encrypting arbitrary files
Since pgp is built into it, it would be easy to support pgp encryption of arbitrary files inside dats. For regular dats holding any data, metadat could handle encrypting the file and saving the encrypted version of the file to the dat, rather than any plaintext. If the dat is shared among users and groups, then metadat could automatically handle multi-key encryption of the files using the pubkeys of all the other users who have access to the dat.
Since dat addresses are private, and data is sent over an encrypted connection, the only advantage of this kind of encryption is if your device is stolen or if someone steals your login.
commenting and messaging on dats and on files within dats
Could potentially have a commenting and message-threading system on dats and on dat files, all encrypted using each user's pubkey
terminology
public dat collections
In order to find and follow cool public metadats (eg "NPR's dats""), simply enter a public metadat address. With a UI, that address could have a clickable link.
following someone
To follow someone, you enter the address of their metadat, which gets saved locally/privately. Then all their public dats can be listed.
adding a contact
Adding a contact allows you to give them private access to certain dats. To create this relationship, both contacts need to initiate a contact request with the other.
On the creation of a new contact requset, a new dat gets generated that will hold the relationship metadata ("relationship metadat"). Once one contact initiates the contact request, that relationship metadat address gets encrypted using the other contact's public key and placed in their public metadat. Once both contacts read each other's relationship metadat addresses from each other's public metadats, then that encrypted address can be immediately deleted from their public metadats.
For each contact, two relationship metadats should be saved, one that contact A writes to and contact B reads from, and the other for contact B to write to and contact A to read from.
Once both relationship metadats are established, then contact A can start privately sharing dats with contact B, and vice versa.
setting permissions on dats
When you create or edit a dat, you can explicitly set which among your contacts have access to that dat. For each contact that you give access, the dat address will get saved into the relationship metadat that you have for each contact. If you make the dat public, then the dat address simply gets listed in your public metadat instead.
user groups
When you set permissions on a dat, it might be handy to give access to a whole group of contacts all at once, without having to select individually.
After a contact is established, you can simply put a group label within the relationship metadat. Each contact could request to be in a group from the other contact. When you set permission on a dat, you can select groups as well as individual contacts.
cross-device pairing
Similar to creating a regular contact, you create a fully-trusted relationship between two devices. Any private dat address on one device would be immediately put in the "relationship dat" and listed and downloadable on the paired device (eg your laptop and your phone). This could be thought of as a kind of "full-trust device network". For each dat you create on any device, you could choose which other devices in your trust network should auto-download the full dat.
local privacy and encryption
Since everything is based around PGP keys, we could encrypt all metadata in all metadats. Even though the dats themselves are private, and are shared over SSL, if your device was stolen, then someone could find all your metadat information. Encrypting everything locally would ensure that simply stealing the device wouldn't expose all your dat addresses. All dat addresses that are shared with other contacts are encrypted using their pubkey.
messaging
Could have some simple device-to-device messaging by placing a pgp-encrypted message in your relationship metadat for someone else using their pubkey.
"forking" UI
If you download a dat and want to edit it, there could be a simple method for initializing a new dat with the edits and notifying the initial dat creator of your edited dat address, kind of like a fork.
data rendering
Say you have a dat with files in a certain format (
.csv,.md, etc). When you click the file, you could choose a "renderer" for that file. The renderer could be a JS/HTML application that takes the file as input . You could simply provide the.giturl of the renderer app when opening the file (and in a UI, the "renderers" would be pre-listed). This would open up potential to build open-source renderers for spreadsheets, wiki data, etc. The renderer itself does not need to be part of the dat, and can just be pulled off github or similar.encrypting arbitrary files
Since pgp is built into it, it would be easy to support pgp encryption of arbitrary files inside dats. For regular dats holding any data, metadat could handle encrypting the file and saving the encrypted version of the file to the dat, rather than any plaintext. If the dat is shared among users and groups, then metadat could automatically handle multi-key encryption of the files using the pubkeys of all the other users who have access to the dat.
Since dat addresses are private, and data is sent over an encrypted connection, the only advantage of this kind of encryption is if your device is stolen or if someone steals your login.
commenting and messaging on dats and on files within dats
Could potentially have a commenting and message-threading system on dats and on dat files, all encrypted using each user's pubkey