I think this is partially correct. As the APP will be what defines how to merge what then they need access to the tip of tree. Where that is more than one value then they must merge that. This gives us a growing HEAD.
The older branches are all in the underlying CRDT tree structure as you point out, but that’s not normally valuable to apps. However in some cases it will be.
So it seems to make sense there is an API that devs use but also a low level API that allows devs to get at the whole tree? It has to be clear in documentation though for sure. This and the fact that unless folk can access it there is data likely inaccessible, so the permenent web part is lost. Therefor we need folk to be able to access the complex messy bits
=D we do have a launch ‘date’ and it seems that the feature set has been slimmed down a bit but from what I hear we seem to have a plan for launching a network more or less on time (that is allowed to fail and evolve later on - which is a smart move and a pretty good plan I think)
Is there a launch party date? for those who are geographically challenged it may need to be a post launch party, going to need those moon coins for airfare
Everyone here just wants this network to succeed, hopefully the team have a few aces up their sleeve to alleviate the community’s concerns. We do need to get this launch right though we only get one shot at it.
If that is true, and I’m not sure whether it is or not, we shouldn’t launching by end October.
Launch to me is token distribution, so the question is what would happen if that has to be withdrawn and done again. Firstly technically, and secondly in the knock on consequences for partners, marketing, runway etc.
The obsession with October makes me worry that it is governed not by readiness but finances, or other considerations that are not shared. But who knows.
There’s no transparency about this. No sense that Autonomi recognise that possibility while the network readiness is questionable. Serious bugs in critical areas being surfaced by one lone external developer, weeks before launch.
I’d welcome some recognition that this network may well not be ready by end of October and at least an assurance that this is planned for.
My money is on over-ambitious promises to corporate partners, presumably made entirely in good faith by our new CEO.
I do not entirely blame @Bux for this - its a very complex project, pushes limits that have never been poked before and her previous experience, impressive though it is, may not have prepared her fully for such a “different” project, especially one with an ethos that will be rarely found elsewhere in the sector. And an aggressive, grumpy bunch of supporters who are at the same time both incredibly patient and impatient but who between them have decades, nay centuries of time on this job.
Its a big ask and its no great shame to have got it a bit wrong.
Expectations need managed and it may well be that our forthcoming corporate partners need their expectations managed if we are all to succeed.
Sorry, I know this thread went in a totally different direction, but I just wanted to say, I got around to updating the documentation regarding the build-time keys:
I apologise for the confusion there, and I hope this makes things a bit clearer.
Can i ask for something else @chriso and that is how does one add in the automatic grabbing of peers from the file kept at this time on DO. The one the safenode release uses.
That is when i use the codebase from github I have to supply the SAFE_PEERS env var and I am asking how to get the built version to grab the file as the release version does.
My understanding is that we will aim to do this now.
The initial impl essentially just said “clients can deal with this” for simplicity. But seems that in actual usage that’s buggy and can lead to issues w/r/t replication.
Yeh, that’s certainly a bug due to the read back verification requiring only one respondent, I believe.
This PR should help there (and force merges in the local client for collected data.
It should certainly be possible access the register history. It should all be there within the register ops itself. It’s about exposing that in a sane way. I now there were thoughts and ideas on how to do this previously, but we never got to them yet.
On the convergence point, there’s work in flight to enable this I believe (still playing catchup somewhat post-hols; which, yes were very welcome @happybeing !)
CRDT data can be merged by any actor. As long as it’s signed then it’s valid for merge. So any and all actors SHOULD merge and replicate this data.
It’s not about clients or nodes, it’s all actors and this is how CRDT data works, eventually consistent data is more consistent the more it’s merged.
The use of convergence as a new verb here is confusing as well. If we stick with CRDT data being data that handles concurrent valid updates and is eventually consistent then we are in a good place.
There should be no confusion over who or which actor does merge, they all should. It’s really as simple as that. So it’s not about network verses clients it is basically ALL actors that should perform merge and replicate.
It was agreed by the Engineering team as a reachable goal. As a project we do need some goals and I am fully supportive of picking a goal and working towards it.
Otherwise, we drift for eternity. So I am all for going for a goal, I know @Bux would have wanted this sooner but this is what she was given and is working with it. So we will see how we get on, but there is some fast moving actions to be taken now to achieve this goal and the team will have to be extremely focussed. My concern is the data types have not been well cared for and therefor the API for builders is terrible. That must be sorted very quickly now, so we can actually know the API works and is valuable.
And are possibly not well tested therefore - how many things you programmed did precisely what you thought/wanted even with testing for a while…? (for me it wouldn’t be many and just very very simple stuff)
All good - you have your plan and if you think it does make sense to go the route like this then do it just an impression from an outsider without deeper knowledge what’s going on behind the curtain
I agree with that, and of course understand the value of having a goal and working to that. My issue is with that appearing to be set in stone regardless of a stream of problems with the core of the network, and what I’m sure is a frantic team environment that has had to neglect important aspects.
Not just a “terrible” API (I wouldn’t have been quite that harsh ) but an API that has not and is not being exercised adequately, to the extent that people like myself trying it out are finding serious bugs - while we have been pretty much left aside and sometimes actively obstructed when trying to help the project.
The core of the network may or may not be sound, but the best way to pick up issues is not just to have folk running nodes and a stream of uploads. It also has to include a lot of testing by third parties flexing the API. That has been almost non-existent, and yet has turned up serious bugs.
You coming back David is one the best things that’s happened in recent months. I hope you are not doing too much, but welcome back
To the wonderful community - please hold the line, at least until you see details of plans, which will come when we have written them up. You don’t yet have all the information, once you do it will be much easier for you to form a view - the good news is being pressured into anything, whether it be from partners or not, isn’t a factor. I’m as stubborn as I am open minded - and like us all want, and will only pursue, what is best for the network.
) but an API that has not and is not being exercised adequately, to the extent that people like myself trying it out are finding serious bugs - while we have been pretty much left aside and sometimes actively obstructed when trying to help the project.