docs: clarify how to build a client that can connect to the public network

[happybeing]

Since I built for the 12th June network the protocol checking has changed and I can no longer build my client in a way that matches the protocol version of the public network (or Josh's latest comnet).

I've tried building against stable-2024-07-08 both from crates.io and a local clone of stable-2024-07-08 and both give the following error when trying to connect to either he public beta or Josh's latest comnet:

Failed to connect to Autonomi Network: Could not connect due to incompatible network protocols. 
Our protocol: safe/0.17/8f73b9_9934c2_b4243e_a58583 
Network protocol: safe/0.17/844186_8829ca_8c0271_8c2f40

I think need to know how to get the correct keys to build against a given version (tag) of safe_network. I see here the set of environment variables which need to be set, but I don't know how to get the values when building my client app.

The instructions there are unclear, and seem to be a mixture of instructions for the Autonomi developers doing a release and instructions for other developers doing local testing so I think that section could be clearer, and divided into things for people working on safe_network crates and third party apps using those crates.

cc @mickvandijke

[happybeing]

Rusty Spork via Discord tells me someone from the team responded...

He needs to setup following env vars when compiling his app: FOUNDATION_PK=84418659a8581b510c40b12e57da239787fd0d3b323f102f09fae9daf2ac96907e0045b1653c301de45117d393d92678 GENESIS_PK=8829ca178d6022de16fb8d3498411dd8a674a69c5f12e04d8b794a52ab056f1d419d12f690df1082dfa7efbbb10f62fa NETWORK_ROYALTIES_PK=8c027130571cea2387a0ceb37c14fec12849015be1573ea6d0a8e4d48da2c1fbe2907ae7503bb7c385b21e2d7ac9d6ff PAYMENT_FORWARD_PK=8c2f406a52d48d48505e1a3fdbb0c19ab42cc7c4807e9ea19c1fff3e5148f3bbe53431ec5a07544aaeef764e073e4b2f

EDIT: That did the trick, thanks. __ I guess this needs to be published and updated for each reset, so let's not close this until a way for versioning has been established.

Feedback and suggestion

I find the above approach odd. It seems a simpler way would be for the 'version' to be a combination of all the relevant crate versions, and then the network could actually output an error saying which crates and versions are needed, and which is wrong in the client app.

The public key check seems strange and may well not match with the APIs unless it is effectively mapped to all the relevant crate versions anyway, so this seems like it could cause issues that are not obvious when people try and use APIs incorrectly, because a crate gets out of step with the public keys.

[rreive]

@happybeing Imo the QA an Release Management Methodology needs a forklift upgrade to commercial management methods to simply in a nutshell, release a zip file with enough time between developer releases to sweep up and collectively validate fixes and change requests on a solid reference platform (not applying a continuous stream of patch/fix to the beta test wave live in Discord)

Again in my experience It's the only way forward to have the nascent Autonomi developer environment and community successfully evolve and mature to generate true high quality value add applications with good adoption rates.

Autonomi Network Third party developers need some base capability they can rely on, published at set intervals,

with the release as far as the Autonomi Core developer/QA team are concerned,

see the entire team have signed on as 'known to work' (within a limited scope) , Tested and validated on the QA test reference platform as a complete implementation,

with a documented technical errata sheet and specifics for each developer release,

for each of the target developer OS version environments supported.

The current Incremental creep approach employed by Maidsafe core dev/qa team is extremely hard to support long term, in my experience it always leads to rapid team pace sag and moral fatigue of the developer and QA staff, always resulting in productivity fade

with the consequences being regularly missed deadlines and team resources going elsewhere in frustration.

The consequences are the community interest in the project starts to wane, et, etc, etc etc.

I hope this helps.

Background: I have 'Been there done those wrong QA and Release Management things'

QA and Release management behaviour I currently see happening in the Maidsafe team,

As the QA and Release Manager at Surfkitchen,

I was able after six months from time of hire there (Zurich) to adjust the release method and schedule as above, for our UK based PS Field solution developers in the UK serving our big customers across Europe, and as a result,

We as a Surfkitchen Team had a few quick 'developer release' successes at Surfkitchen with the PS team developing solutions with our core releases employing the above method ,

This change in the Zurich located Core development Team's QA Release delivery method packaging and release cadence immediately helped UK PS serve notably O2 Ireland, France Telecom/Orange to

more quickly,

with much higher quality and

less team member stress,

better support the Mobile Provider collective deployment of what was 69 early symbian smartphone set model types (strung out across three different Symbian versions) , from at least 15 Different Mobile Phone Vendors, with 5 different server provisioning versions (SunOS, Linux, MS Server) serving

10s of thousands Early Smartphone Mobile Provider user communities down loading the SymbianOS configuration and ringtone and early game app updates to their mobile phones to change their mobile phone

skins,

ringtones,

early games

versions

AS a result, Surfkitchen did have more adoption success for their Symbian centric Mobile Phone Subscriber Management System with other Mobile Providers across Europe thereafter,

and Surfkitchen was even successful in deploying a Symbian Mobile Phone Subscriber ringtone, skins and early game download solution for Telstra in Oz,

which eventually led to Surfkitchen's somewhat successful 'Symbian centric' exit to Teleca just in time before the Apple iphone was released.

Much of the Manual QA UI/UX at the time was offloaded to Accenture India (before that it was Perot Systems India) .

The QA Release packaging method and cadence change described above works, as you hint in your note.