Closed jayrbolton closed 7 years ago
I'm ok with adding readable users using a separate function only instead of in the createDat
one. The less each function does the easier it is to test and maintain.
sure, there can be a separate function for posting a public dat vs selecting specific contacts. Once groups are implemented, I think that logic will be the same as posting for a 1:1, so that might be the same function
I thought it might be simplest to have three functions for createDat
, makeDatPublic
, and shareDat
, so I went that route in the latest update.
@karissa I updated the Readme to make it better reflect what I'm currently thinking for the API. I was also thinking of taking out any kind of user-naming (ie, right now the user can have a name, can name their dats, and can name their groups, etc). Instead, we can only use IDs and hashes for everything. A higher-level library could handle stuff like naming, messaging, etc, which might depend on the use-case
the
createDat
function could take an option for who you want to share it with, which could be an array of user ids. That dat address should be placed in adats.json
file inside each push-relationship dat for each contact.