I’m thinking of apps that provide some kind of building block that isn’t really a full user app by itself, such as maintaining discussion indexing or membership lists, that are then used by an end user app to create the end user experience.
Maybe “app” isn’t the right word for these – “service”, “facility”, “library”, something else…
These “services” could add a lot of power to structured data in the same way C++ classes do for C structs.
If there is such a way to contribute at this level, I’m guessing they need to be made available in the variety of forms that apps may take – javascript, linux shared libraries, etc.
Would the launcher get involved?
How would a developer of one of these earn safecoin as a contributor?
That’s what I had in mind when I did the write up for SAFElate translator on www.tiny.cc/appsite and I think that’s what @dallyshalla has in mind for SAFEx.
These are like core apps for translating or trading, whose capabilities can be called like a function into all sorts of other apps.
Plugins or addons could be another metaphor and yeah this kind of thing could be very useful. Though I get how you’re saying it would be across apps and more on the programming level. Such libraries or classes could be useful in creating new apps as well as much as the heavy lifting would already have been done. Though I’d caution against getting too heavily dependent upon building layer upon layer of these classes. Look how various distros of Linux work and if one if the dependencies are missing the whole app chain can go to hell. I think if we were to take such a modular approach using classes/libraries or blocks is that we’d need an app to track and manage the modules.
I’m interested to see exactly how much the safe_launcher is integrated into the app API calls. That may be the place where addons/plugins are integrated.
But, if we don’t have some kind of modularity, then each app is its own monolith, having to develop all its features from scratch – shopping cart, discussion management, etc – things that are so common to lots of apps. If someone else wrote a shopping cart module, why should I? His might be the best available.
I agree, however, we can take modularity too far, to where the management of the modularity becomes problematic.
At a simple level, there is nothing to stop the data for the application being distributed.
In the same way as web services on servers around the world can be interfaced with other systems, the same is true for data stored in distributed vaults.
In theory, you could have changes to distributed data cascading through many other applications. Each application would update its own data, based on the data it pulls from elsewhere.
Each application could run in isolation in such a system. Moreover, the data could be cached and distributed the performance.
Ofc, latency would be a limiting factor factor here, but until vaults can execute user code (as well as store data), this would be a viable model.
The intent is that the message contents and the Header subject
can be a serialised anything, so different apps will encode different
structures into the data field. Your app should therefore be able to
tell which messages are for it by parsing the Header.
Additionally, apps could perhaps create their own MPID on behalf of
the user to ensure that the messages for the MPID are all for it.
@Traktion, maybe I’m missing something in your response, but I’m less concerned with storage than with usage.
I want to make use of feature software, such as a shopping cart, within my app that someone else wrote (or conversely, to be able to build a shopping cart module that other app developers can use).
So, even if the shopping cart module stores its own data, I want to be able to invoke “shopping_cart.add_item(‘abc123’)” from within my app, then “shopping_cart.list_items()”, without having to know any shopping_cart storage types.
@digipl, are you suggesting a remote service type of model? The two apps are independent and one provides services to the other. Interesting.
So, just to think out loud…
A service app may have little to no user front-end, just a messaging API. Although, I guess there may be value for a user to interact at the service level (e.g. having a shopping cart app show you everything you’ve purchased everywhere. Or a struggling husband blocks his wife’s shopping cart privileges… Hah!).
If messaging is to an MPID, then such an app could be running anywhere on the network. Any running instance could/would handle the request, which means some kind of “customer” or “cart” identification (app+user should do it, I think). Is it possible that multiple instances could answer these requests?
The user app would have to indicate somehow to the app launcher any service apps it intends to use, which would then have to either locate them on the network already running or launch them locally to handle requests.
How would “locate them on the network” work? How would you make sure that a remote instance stays running long enough for your use? Maybe we just always launch locally.
EDIT: I realized I may be misunderstanding MPIDs. When I launch any app, any MPID it creates is probably instance-specific (like a socket endpoint), not shared among all running instances. If so, then my above thoughts/questions about multiple instances and locating apps on the network are moot.
As storage can be immutable and distributed, you could potentially link/include published code/libraries in-situ. In theory, as all data is chunked and distributed, I don’t think there would be a performance penalty compared to any other related data stored.
I suppose you could do something similar with the current hosted internet, mind.
I thought there was some sort of payment system where everyone gets proportionally rewarded for their pieces of code that are used, cause all data (including code snippets) is individually signed to the original creator (uploader’s) wallet
If I understand correctly, the reward system applies when you specifically download an app, which is done in some way other than just a simple network GET (maybe through the app launcher, I don’t know). If all we do is directly GET plugins, then we’ve bypassed the app rewards mechanism.