A question has been forming in my head over the past few days, don’t quite know how to put it but I’ll try:
How much of what we’re doing could potentially be overlooked completely if SAFE gets mass adoption?
Like, things like MaidSafe’s particular instance of a launcher, or things like StructuredData, or or certain other things. Might people just overlook certain parts of this completely and develop how they want on SAFE?
It would be very helpful to maybe try to make two lists, like these:
Essential things that can’t be sidestepped:
farming
SafeCoin
vaults
Things that might be sidestepped:
MaidSafe’s launcher
MaidSafe’s APIs?
Ideas like StructuredData / AppendableData etc
I guess my question boils down to:
What if people were to just take the core invention of this serverless internet system and run with it in new directions? What would be the things that wouldn’t be easy to recreate / develop around? (1st list)
*Disclaimer, it’s quite late and that’s when I come up with my densest questions, admittedly
Well you need to interface to the network. So the launcher or its replacement is needed. You have to generate the packets to place on the network somehow. They also must follow the protocol used by SAFE.
Without the APIs then SAFE becomes a simple data store. Dropbox replacement.
Without SDs there is no directories and simply a flat dropbox replacement. SDs provide the variable data store for SAFE, also the structure for SAFEcoin.
Really the API, Launcher, & SDs were created because they were needed to implement
Not sure what you’re chewing on @whiteoutmashups, but I’ll guess.
The different aspects of the core of the network are there because they depend on each other, I think. Maybe certain aspects could be taken to do other things on other networks, but I think (as @neo points out), that if you omit some of them, you don’t really have the network.
Perhaps someone could implement a launcher (or way to bypass it) which was not secure, etc., and still interface the network, but that really wouldn’t affect the network as a whole, just the users who used it.
Being open source, any aspect of the stack can be forked and put to other purposes, but I don’t think just ignoring key elements of the stack and trying to move forward on the same network will work very well for anyone.
I think we have to assume that there will be many different apps which interface with safe_core (FFI client library). Safe_launcher us the first, but I doubt it will be the last.
Whether people will go lower level is a good question, but people will have to be convinced you run any alternative code. Malicious clients/vaults will likely become rejected and defended against quickly, bug well behaved implementations should be welcomed.
Edit: recently, ethereum came under attack through crafted transactions which sent some nodes into a spin. It would have been worse had there been only a single implementation, as only the Golang version was exploitable, leaving other implementations unscathed.
I guess I was thinking that these would be the easier parts for people to make competing / alternatives for.
On the other hand, the whole decentralised data, vaults, incentives, etc etc are really very sound and probably the best possible way for this to ever be accomplished.
I was really thinking long term, and trying to guess which parts would be the most likely to stand the test of time. I can’t think of a better way to implement “nodes” than what we have, but might people build on that and interface with the network in completely new / different ways than what we’re currently working on?
I know it’s a strange question, and it mostly stems from the fact that there’s so many concurrent breakthroughs bundled in what we are calling “SAFE.” I always wondered which ones would “stick” the most, and what kinds of alternative launchers / APIs etc people might come up with down the line.
I mean, that’s a part of the reason MaidSafe has it’s 1% rule (1% royalty to MaidSafe when you aren’t using their APIs), unless I’m misunderstanding (totally possible, like I say, very late )
And I guess the main reason I even entertain such questions is as an app dev, the core tools and commands are always changing / being updated, and I was imagining that this could possibly start to happen even more if other companies with different ideas create different systems for interacting with the network. Just trying to mentally map out the entire scope of what I might need to adapt to
Thanks for this, it’s a perfect articulation of my question
Where did you get this from? are you talking about the licensing fee? if so, it doesn’t have to do with the API but just the usage of the network by a company not accepting the GPL license.
Thanks @whiteoutmashups.
So what I understand is that if you are not using the API but you decide to comply with GPLv3 license, then the 1% fee doesn’t apply, and that’s what I was trying to point out.
Now, I assumed in that context that the API is in relation to high level API, i.e Launcher’s REST API, thus “not using the API” means:
Using the low level API exposed by the safe_core library
or developing your own safe_core that I’m not sure if it’s possible, I presume it is…?.. (I’m assuming the safe_core is just the client). If it’s possible I don’t know how the licenses apply.
If I was assuming correctly, then what confuses me is that using the safe_core lib’s low level API implies linking your app with it (???). In this case, according to the license notes in the safe_core library, you can also opt for GPLv3 or commercial license. I thought that linking against a GPL lib you are forced to give your app with GPL. I admit that these licensing thing was always confusing for me so…
The distinction is that if as a developer you ‘link’ (when you create a binary compiling SAFE Network code and yours) to SAFE Network code then you need a license, either the GPL v3 or the commercial license. If you use any of the REST APIs (https://api.safedev.org/), then you are sending messages to REST so you can license your derivative works anyway you like without needing to consider GPL or a commercial license.
