Update 02 December, 2021

It is enough to have working cat and put.
But it is, of course, possible that everything is working well except those two :slight_smile:

1 Like

I found why the network would not start with my previous attempt --skip-igd has been replaced with --skip-auto-port-forwarding but cat is not working for me.

edit: cat is working but only on 2 of 3 uploads which may point to,

5 Likes

I’ve often felt the same way. Every time I start thinking to begin dev on a safe app I feel like ‘if only we had a stable api’ or ‘if only there was a mock’ or ‘just the basics would be enough’ or ‘maybe I could write a wrapper’.

But when I try to come up with a concrete proposal for something to help me (and other devs) get started on app dev, the checklist explodes in complexity pretty fast.

  • I only want a simple GET - what urls will I call that on though? PUT must come first. Maybe a read-only network with permissioned PUT (ie only I can PUT) could have some use? Read-only will be a very common way to use the network (eg virtually all first-time users will be read-only).

  • I can implement a PUT call - but now there’s some real questions about how to manage accounts and costs and insufficient balance and onboarding, since PUT is exposed to a huge number of potential errors and I can’t really make an app without knowing the various errors to show users when they inevitably try to click ‘save’ without having an account etc. (see note below)

  • If PUT requires an account, I need to have some concept of registration and login/logout/switch for my app if it’s anything more than read-only. What’s this flow look like with SAFE? Can I stub it out? Not really because I don’t even know what stubs to create. It’s probably not going to be like a standard web login.

I feel like this all points to the question ‘when can maidsafe freeze the API’? If the api can be stable, even if the logic behind it is all fake, we can at least begin to develop around it.

We’d need more clarity on payments (storecost and the actual way payment is presented to the user). Also more clarity on PUT errors (I feel this will equate to more clarity on onboarding since an account error will often end up going directly into an onboarding flow). I mean at the API level, not the GUI level.

And finally we also need more clarity on the cli api vs the rust api vs bindings, since an app dev would consume each of those apis quite differently.

I would LOVE a mock api that talks to S3. But so far I’ve not really come up with anything that would really allow me to dev with confidence. Any ideas?

[note about needing to expose account errors]: If a mock api doesn’t expose errors that enable the developer to move into an onboarding flow, the developer is more inclined to ‘hide’ that messy unknown aspect. This bit of code legacy in their app will later act as a temptation to continue to ‘look after it themself’ and instead of replacing their workarounds with a proper onboarding flow they may keep the dataflow totally within their control and pay for uploads themselves. This introduces the risk that users will not own their data. This is about setting a cultural norm, and I reckon there’s a risk if we don’t make onboarding errors trivial to solve from the start we could undermine some of the core principles of the network (such as owning your own data).

It’s probably always going to be simpler for companies to ‘own the whole data flow’ rather than managing a whole bunch of different ‘user controlled data flows’. The early dev experience here will set the tone and norms, so hopefully we can do good things with it and avoid companies taking control of user data because ‘it’s easier to own everything within the company’.

16 Likes

Working cat and put is needed to just be able to say “it works”.
Exact mechanisms may be changed many times later.
But “it works” milestone is important nevertheless.

4 Likes

Haha - I’m glad he is - actually I was wondering the same today and therefore found your response here :face_with_monocle:

Glad to see you’re still alive and around :slight_smile:

6 Likes

Thank you for the heavy work team MaidSafe! I add the translations in the first post :dragon:


Privacy. Security. Freedom

5 Likes