Comments

• 

  over 6 years ago by mslacken | Reply

  Status

  Looked into different blockchain solutions which gpl compatible, but could not use anyone * openchain (implementation is in C# which may be complicated to compile) * multichain (to focused on bitcoin, streams could store data, but are not specifcally tailored for signed/cryptographic exchange) * ethereum (package could not be built, did not want to use go implementation)

  Implementation Ideas

  • use json-glib for inpput and output
  • libgpgme for cryptographic signature

  API idea

  Everything will be an to be named object of following kind. It will have following properties

  • uid (integer), mut be uniq
  • name (char*) must be uniq
  • unsigned int modified_by contains the last uid which modified this entry
  • unsigned int allowd_mod conatins the uid(s) which are allowed to modify this entity
  • char* last_sig contains the signature which made this entry valid
  • mod_time is the time when this entry was created/modified
  • valid_until is the itme until this entry is valid (could be removed as a keyistelf could also have a validity date)
  • private_key
  • public_key
  • json_data (addtional data, would be type of an entry, for group the entries would the the gids ...)

  Basically all user managemnt stuff could be dealt by exchanging messages like this. There will be no possiblity to modify entries, just replace/write them completely. First implementations will use the broadcasts for communications.

×
Edit Comment 3568
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
#Status Looked into different blockchain solutions which gpl compatible, but could not use anyone * openchain (implementation is in C# which may be complicated to compile) * multichain (to focused on bitcoin, streams could store data, but are not specifcally tailored for signed/cryptographic exchange) * ethereum (package could not be built, did not want to use go implementation) # Implementation Ideas * use json-glib for inpput and output * libgpgme for cryptographic signature # API idea Everything will be an to be named object of following kind. It will have following properties * uid (integer), mut be uniq * name (char*) must be uniq * unsigned int modified_by contains the last uid which modified this entry * unsigned int allowd_mod conatins the uid(s) which are allowed to modify this entity * char* last_sig contains the signature which made this entry valid * mod_time is the time when this entry was created/modified * valid_until is the itme until this entry is valid (could be removed as a keyistelf could also have a validity date) * private_key * public_key * json_data (addtional data, would be type of an entry, for group the entries would the the gids ...) Basically all user managemnt stuff could be dealt by exchanging messages like this. There will be no possiblity to modify entries, just replace/write them completely. First implementations will use the broadcasts for communications.
 
×
Reply to mslacken
Status
Looked into different blockchain solutions which gpl compatible, but could not use anyone * openchain (implementation is in C# which may be complicated to compile) * multichain (to focused on bitcoin, streams could store data, but are not specifcally tailored for signed/cryptographic exchange) * ethereum (package could not be built, did not want to use go implementation)
Implementation Ideas
• use json-glib for inpput and output
• libgpgme for cryptographic signature
API idea
Everything will be an to be named object of following kind. It will have following properties
• uid (integer), mut be uniq
• name (char*) must be uniq
• unsigned int modified_by contains the last uid which modified this entry
• unsigned int allowd_mod conatins the uid(s) which are allowed to modify this entity
• char* last_sig contains the signature which made this entry valid
• mod_time is the time when this entry was created/modified
• valid_until is the itme until this entry is valid (could be removed as a keyistelf could also have a validity date)
• private_key
• public_key
• json_data (addtional data, would be type of an entry, for group the entries would the the gids ...)
Basically all user managemnt stuff could be dealt by exchanging messages like this. There will be no possiblity to modify entries, just replace/write them completely. First implementations will use the broadcasts for communications.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview