Or maybe let’s agree on the names.
autonomi-utils or autonomi-hld or autonomi-highlevel or …?
autonomi-book or …?
If this post will get 5 likes, and no discussion, I’ll choose by myself 
2 Likes
Yes, that’s the one. I don’t want to spend time creating a PR without ok/support from anyone.
I think app identity would best be separated from formats (and kept orthogonal). So yes, ideally we define formats - Autonomi have done this for Archives but nothing else comes to mind. It’s a big and difficult job the higher level you go, so maybe best to keep it simple.
I’m not sure how to take it forward because as we see, people are already rolling their own to turn the lower level into something suited to the application.
Maybe we should start by suggesting preferred criteria such as open standards, non-proprietary and point to third party standards which meet these such as HTML, Markdown etc, maybe and to preferred encodings such as plain-text, JSON and RDF. I’m sure there will be quite a few so we can group them into categories and rate them according to the criteria we want to promote.
2 Likes
One thought I have related to this… is it’s always easier to talk about something real, than theoreticizing. In this regard PRs are better, than issues. On the other hand – they take much work.
Good idea. I imagine all the suggestions could be gathered in form of a PR to CONTRIBUTING.md, a standard file for such stuff, and then discussed/extended in that PR, what you think?
5 Likes
Excellent to see this collaboration.
I wish I could contribute more meaningfully, but this is exactly the kind of down and dirty work that the community should be supporting, its making this network even more our own by starting out on good, well-organised foundations.
Well done to you all here.
EDIT: not really my business but I’d vote for autonomi-highlevel if asked,
And also to add
Carefully considered decisions on this over the next few days/weeks could save a shitload of hassles further down the line in months/years to come. You have the opportunity to make it much smoother for those who follow.
3 Likes
Yes, I’ll publish to its own wee library. Easier to maintain and just pull in the one lib/dependency too then.
It just takes an XOR and streams Bytes, so its pretty open.
6 Likes
That would be great. 
A request: accept address or datamap, so it works with private Archives.
2 Likes
I suggested autonomi-util because its somewhat common in the Rust ecosystem, e.g. tokio & tokio-util, futures & futures-util, hyper & hyper-util …
But the name might limit a little what we can put in there. How about autonomi-extra? This could hold pretty much anything that’s generally useful but outside the scope of the core autonomi crate?
I can imagine a structure like this:
├─lib.rs
├>io
│ ├─stream
│ ├─sink
│ ├─reader
│ └─writer
├>data_types
│ └>high_level
│ └─history.rs
└─utils
We can start with the things we have right now, and then let it evolve over time.
3 Likes
Guess where this is going to be tricky…
..LICENSING
Maybe there will be agreement on GPL in line with Autonomi? I would accept that for my contributions (all my own code is AGPL). I’d be reluctant to contribute anything more permissive.
1 Like
I don’t think there is much of a choice right now. The autonomi crate is currently GPLv3 licensed, so if it’s ending up in autonomi-extra’s dependency tree, I’m pretty sure we have to GPL it too.
I’ve voiced my opinion about this already.
2 Likes
Good, I didn’t think we’d get off to such an agreeable start on that. Appreciate your compromise as it is less than my own (I’d still prefer AGPL 
) and @loziniak doesn’t need to move an inch. I’m not sure if everyone will agree so easily but pointing to Autonomi’s licensing is a powerful point 
2 Likes
I’ve created the repo:
No one opposed, so it’s GPL.
…and same with this.
Maybe you can file an issue, and somebody will pick it up eventually? I personally have a hard time grasping what the idea is, because I haven’t used Archives.
I would strongly be against adding dependencies out of autonomi tree, so we’re still good I think. Also, you loose advantage of having your code reviewed if you keep it on your own.
They also have Registers as a higher-level abstraction, right?
2 Likes
Though it’s a bit different from a format so 
All that Registers do is give you an append only structure for an arbitrary value that can be a pointer to other data. History is almost identical underneath (I literally rewrote the Register code), but for a generic type so you have an API that handles more of the work, and includes support for object naming, keeping history in a separate name space and so on.
Whereas (FYI) Archives define an underlying format for more complex metadata (paths, filenames, modification date etc). In one case this is mapped to datamap address (public Archive) and the other contains the full datamap for each file (private Archive). That’s the only difference, so if somebody knows the address of a private Archive, they can access all the metadata and the files.
1 Like
Tagging this thread on Discord about ideas for single login and app IDs. It begins back up the thread where @dirvine posts about app login and key management.
If we want to work on this we can open a topic here or on the github.
3 Likes
Discord is a terrible format for asynchronous communication like this.
1 Like
I agree, in the thread I suggest coming here!