This began as a reply on your topic but I thought it best to separate it, and open it to all the developers interested in this suggestion…
I’m curious if you have considered developing a library for incorporation in other apps to enable them to run a few nodes with minimal setup other than installing the main app itself.
I’ve been pondering today ways to simplify getting on board and using Autonomi for as many people as possible. How to simplify setup, creation of a wallet, initial funding and so on.
dweb is a step towards this, and could easily incorporate all these aspects (eventually!), and include a web GUI for wallet, nodes, single login etc. I don’t have time to do all these things on my own so wonder if any of this is of interest to you and others.
I think others would be interested, @Riddim almost certainly, @Traktion might be interested in having these features in AntTP, and anyone building apps with either would also benefit from making things as easy as we can for everyone to gets started and use multiple apps once they’re on board.
Most of the developers here would benefit from some aspect of this, such as single login, a feature that seems to have been let go by Autonomi but could still work IMO. There has been some discussion of this recently, but no conclusion.
Anyway, I’m curious. What do you and others think about designing something to make it easy, perhaps based around dweb and AntTP and any other Rust app platforms, incorporating these base features including aspects of Formicaio?
We’ve been thinking about including single node during work on Jams, and I have this in plans for safeapi. But it could be made as a standalone lib/module also, or a PR to official APIs. I’d happily collaborate on this. Sorry for being quiet, I haven’t noticed this topic.
I did not use Formicaio, what features exacly do you mean? In safelibthere is simple login with an EVM key, this could also be provided to a node, so no additional config would be required I think. As simple as possible.
Actually, I think this is something exactly that I’d need:
@chriso is ↑this↑ all one needs to spawn a node process in application?
Single login would also be nice, but I haven’t thought about it until now. I wonder how it could be done. Maybe first app, that connects to Autonomi could create some file with login info (secret keys?), and subsequent apps would just get that keys? To keep keys uncovered, maybe this first app chould provide some RPC service to act as a wallet and sign all other app requests.
Hey, the node spawner has been developed mainly for testing, but I don’t think there would be anything stopping it be used for other purposes. I would need to clarify with some of the other devs.
There are two (at least!) forms of single login I see:
for all apps which is what you are thinking about, and
for all web apps
dweb already provides that for all dweb apps and avoid the need for individual apps to ever get the secret key. Only dweb has that, and apps delegate use of it via the API.
So if all REST APIs follow a common way of doing that, we could have a single login for all web apps which is a good place to be.
I’ve not got a good solution to the first case though. I’m not sure it’s a good idea to have separate keys per app, or for them all to share a key which they have direct use of.
So I think your idea of delegation in that case works too, and maybe that could be done by dweb or similar REST servers serving other apps.
I think it would be a nice option to have apps that earn ANTs, but I wonder whether keeping the concerns separate is nicer from an architectural perspective. Building more monolithic apps, which do multiple duties, feels a little at odd with the distributed ethos.
That said, it would be nice to have the option to include a node runner library and wrap it as desired. It could lead to more sophisticated node runner apps (nice UI, metrics, easy to use, etc), as well as hybrid apps which just node run in the background.
I would prefer that the apps have the option to initiate a node that runs separate and continues to run (if desired by user) after the app finishes. When the App starts again it recognises the node and will not start yet another.
That way the user is earning ANT to pay for the App even when the App is not running. I might listen to Jams for a while while I am doing other things but when I get to work on the computer I would shut down Jams (yea I might not too), but the node is still running building up reserves. Could be a “friends” instance, or whatever.
To me having a node running to pay for an app requires it to be an app that runs all the time. Maybe a file-system extension app. Browser gets shutdown often during the day for many people, so any node it runs could be stop-start and if too much actually a determinant to the network.
Yea Apps running nodes inside the App proper really only makes sense for “always on” Apps
I’m working on this way of working for dwebso people don’t have to run dweb serve.
The change will mean that when you dweb open an app the command checks for the main REST server and if necessary silently starts it before opening the app.
When you finish using the web app the server will still be there until you shut down.
So if the main dweb server were to run node, the behaviour you want is exactly what you’d get. So an easy win. Once I have that feature in place it might be worth trying this too.
I’m thinking of the offline Alius books/short names/local commerce (?) idea, so
take a Protocol-First Approach and design as an open protocol with reference implementations, avoiding philosophical misalignment of making some monolithic thing?
Hi, I noticed you’ve deleted all your posts. Did you resolve your issue? I couldn’t get someone to look at it yet, we have a lot going on just now. We’re preparing a release.
