Thanks again Josh, you’ve given me an idea so I can achieve my goal (LDP that falls back to www in apps that don’t recognise the former) without decorating the subName.
All I do is create both services on the same subName (so using service key ‘files’ for www and ‘ldp@files’ for LDP) so the same web address supports both, as in safe://files.happybeing.
I’ve been through several ideas for how to support this, but hadn’t thought of this. It’s much nicer and allows one service to enhance/override another at the same web address, just based on what the client supports.
So long as the RDF implementation allows multiple services on the same subName I am happybeing Where should I record this aspect as a feature request so it will be picked up at the appropriate time?
Providing different @type info or other details in the RDF can facilitate service discovery. In the example above, an email application could resolve safe://happyurl , and as the default value is a Files Map (which is does not want), could search remaining keys for something of type: inbox and resolve this data automatically.
But if you have more to add or want extra clarity it may be worth opening an issue there to add more thoughts, or in the thread on the dev forum
One thing that is puzzling me is that given the focus on MVP and getting the features essential for vaults at home with test Safecoin and the new data types, we have lots of Dev activity going into the CLI which seems a very ‘nice to have’, but not on the critical path.
Hopefully more light can be shed on that next week. But in short we are thinking in terms of MVE (minimum viable experience) rather than pure MVP. And many tracks can run in parallel in this case, without effecting delivery time of coins or vaults etc
My understanding from what I have read somewhere on this forum is that while front-end is perhaps technically not a critical part, it is not easy to send the team on leave until later, and indeed we are dealing with people. And people working on front end typically cannot do back end stuff because of a different required skill set.
So MVE as a target is the result of such practical considerations I suppose, and not because MVE would be necessarily be better than an “MVP” target. Right?
MVE = This is what it will look and behave like, we just are not decentralized yet I assume. And in parallel people working to try and solve some of the mysteries of the backend/routing problems. Front end team finishes all kinda good UI stuff and mock behaviors we can see and then to follow will be some of the backend deliverables that will take more time.
Backend team delivers then the MVE turns into MVP I would hope.
Maybe not that relevant here, but would I develop something new, I would start with a cli to test all functionality with start arguments and perhaps a configuration file and system variables and after that I would implement a graphical UI (or let others do that: everyone has their strengths).
Of course I would not put a lot of time in the cli. For instance an interactive cli is more a ‘nice to have’ feature in this view.
Apologies if this is a bodgy typo strewn reply, typing on handed with a sick toddler on my lap…
Not quite. Although I realise a lot of this comes down to the definition of these terms. Let me see if I can clarify.
What we require to successfully ‘float’ a Network such a as this is more than just a minimum set of apparatus, shown to be working in the way the RFCs describe (an MVP). Given that the integrity of the network and the balance of supply/demand of data required for the economy to flourish will necessitate a tipping point user base, we can’t just go all in for an MVP and not design for what comes after.
What is required is a core set of usable, understandable, trustable features, ready to be adopted by more than just those comfortable with the command line, or installing a Linux distro.
This, and a set of features that can be adequately described, or marketed, to our target users are what make up a MVE.
So its roughly MVP + CLI enables us to build MVE atop. And as I say many of these tasks and teams can be run in parallel with out any effect on the MVP appearing. This is one of the reasons why we’ve separated out Network milestones from FE milestone set in the roadmap. There is no need to sync them, but they can happily bolt down together to make the MVE when they are done.
I would like to ask whether a user base (that is clients not vaults) is critically needed to keep this network secure, or solely to stay ahead of a possible unofficial SAFE Network clone network?
I meant the hypothetical case of many people volunteering to run vaults for free, but without any client users using the network (i.e. no puts and no gets).
There would be a network but would it be insecure and vulnerable?
Na you don’t really have a Network then do you? You just have a few folk who have decided to install the same binary, but have no reason for doing so. No data to be farmed, no rewards to be had, no purpose, no currency etc. They won’t run vaults up and waiting for long.
It’d be neither secure nor insecure. Nothing to be hacked, nothing to be stolen. Just nothing.
yes it will be. If we have 10000 (or 100 000) vaults that are connected in different groups, we will have security even if no one has uploaded and 1 mb of information…
Where should I record this aspect as a feature request so it will be picked up at the appropriate time?
