Update 02 May, 2024

Given David’s “No free lunch…” & Happybeing’s collective dream-crushing of my UX expectations, I’m still looking forward to some level of user interface!! :sunglasses:

2 Likes

What would a gui even need? A button for connect/disconnect, a connection status, live wallet balance.

Isn’t this simple for someone to create themselves?

I mean I don’t know much but even I managed to use python to trigger an excel macro to harvest some data in a spreadsheet, create a doc with it and email it. And I was very proud of myself too.

6 Likes

As you should be

5 Likes

I’m thinking about the following scenario:

  1. I ask/help/persuade someone to run a node or several.
  2. His connection or device get slow, for whatever reason.
  3. He calls me and asks if it’s the nodes.
  4. What do I do?
3 Likes

Those are valid points but here we’ve been given the impression for some time that there would be a GUI to make running a node easy. :man_shrugging:

The two can and should probably be separate, and so the GUI would be optional to help get going and show if things are working.

I had imagined you were planning a very minimal node status app with a small subset safeup/node-manager like capability showing node version, status, earnings etc.

For a while though it’s been unclear what Autonomi has had in mind beyond - it will be easy to run a node and there will be a GUI, which I think has lead to misunderstandings and incorrect expectations.

My aim in asking about this has firstly been to clarify rather than to argue for a particular solution, and then to point out the incorrect expectations I think many here have gained.

Now we’re debating what the end game might be regardless of what is planned for beta.

6 Likes

Sooner or later we all (mostly) want that.
This is sooner, the GUI will be later. Lets get the network lauched with tools that do the job, even if they lack some polish and familiar buttons.
Anybody joining in before launch will be well warned that not everything is as shiny as it will be but that it works mostly as described and they reason they are getting rewards is to tell us when it does NOT work.

Frankly I’d sooner have any excess dev capacity ( I know, I know…) go into a fault reporting tool than into a polished GUI node-manager, We will get far more value from bug reports delivered in a std format than enticing those who are at their tech limit to try out something and then not be able to communicate their failures.
Cos thats what we learn from, not nice testimonials about how comfortable and non-threatening the whole UI was -welcome though they are,

And no, “file an issue on Github” is not the correct response to a n00b. Its a perfectly correct response from @happybeing to the rest of us old team, but not to the n00bs.

2 Likes

In my opinion GUI is more important in the client.

But some way to see what the node is doing would greatly help in building trust to this unfamiliar app I’m going to ask people to run.

5 Likes

:dart:

:100:

Its just not going to be a polished GUI version in the timeframe. It WILL be a fully functional, easy to navigate interface that may be a little unfamiliar to those who are spoonfed perfectly kerned text in the size colour and font of their choice - is that such a huge deal? Especially as a pretty GUI will inevitably be available from 3rd party devs if not Maidsafe themselves within a few months.

8 Likes

Just a couple of things:

  1. We are planning a full GUI
  2. A TUI will be able to do these things

And a 3rd:

We can get wins within days (not weeks or months) to make the UX better, and get more people involved.

None of this is an either or. And we can (and will) keep iterating towards our goals.

And we don’t need to leave out either advanced users, nor headless setups to do any of this!

17 Likes

100% agree Mark, I see this too. Here’s my gut reaction

  • Should the node be part of an app for many users (browser or comms or wallet etc. maybe their AI chatbot)?
  • Should advanced users run nodes with advanced stuff like TUI
  • Should there exist a GUI for control over many nodes on many machines in a site/multi site setup?
  • Do normal users want to run only a node?

This, I feel is certain and how it should pan out.

6 Likes

Yes, but more options == less use? The paradox of choice is real. The Paradox of Choice - Wikipedia
We convince ourselves it’s not cause we early adopters will do anything, but mainstream will turn off.

The big thing it needs is an environment NOT FOUND on small headless devices that many here are running. The gui version would not install on them.

Why though? To bore them to death :wink:

Seriously it’s a big deal for us lot. We know what it means, but users will need value, so apps. Perhaps earning is enough value though??

Let’s reset that expectation and dive deeper into delivery of this network beyond any bits and pieces, but looking bigger picture.

I am not arguing for the sake of it, but seriously pondering what will make folk USE the network as well as what will make folk RUN the network? I think here in ur place we think run nodes and that’s on me and the team, it’s been so much a focus recently and rightly so. But now I think we need to say, let’s make that boring. Let’s make it invisible. Let’s now show what this baby can actually do and I feel that means apps?

The outlier is earning as that could be massively important to some AS LONG as there are others using apps?

This is just all brainstorm folks, I hope nobody is offended or feeling debated with?

5 Likes

Not me. I get frustrated with lack of clarity some of which is inevitable but seems to have increased this year. Three years ago and earlier I could have answered someone in detail about what is coming, but this year I can’t do that.

I’m always “on-side” because I know and trust the team and community. My concern is the impression that may give others as they arrive and also how to answer people’s questions, particularly at the less technical end. Not a problem yet but sooooon.

One of the interesting differences here from say Socket Supply is that for them, every app is a node. Here we have separated concerns, for good reasons which I think will make Autonomi far more capable, though it leaves us with the questions we are now debating.

I think it might well be good to have an easy way for apps to be client, node or both in a third party offering, but we’re a bit early for whether and how to do that. Once things really are at the stage where it is just click “earn SNT” and no more, it may be attractive.

Back to today we have two user visible things to deliver:

  • easy to run nodes
  • good UX for a set of basic but essential features (wallet, file sync etc.)

Each may go through iterations governed by audience (beta/tech v launch/general public) and team priorities. I find it harder now to argue for a particular approach than ever. I remember the App Launcher which seemed a neat way to handle this - a kind of personal app store. That would be a nice approach but we don’t seem to be able to consider that. Then there were the USB apps that would work with a mounted Safe Drive and not leave a trace. And of course Jim & team’s Safe App with lots of functionality in a well thought out UI.

We had quite a few neat UX approaches over time and here we are a few months from launch not clear - for me anyway - on what that will look like for those hearing about the project or some secure, private etc p2p Autonomi app and wanting to know more!

8 Likes

How about

  • Nodes are cli/TUI only
  • autonomy-launcher - Launch nodes and manage them via GUI, Launch and add apps (plugins/extentsions etc.)
  • Stand alone apps
  • Stand alone apps that also run nodes, but build in their own management

We could say we are 25% there(ish)

10 Likes

I think I know many people who would like to support the cause, a secure network ensuring privacy of the users, run by the users.

But even if they would sign up for the idea, the practical reality is very sensitive to details which might make it seem like “some crypto software jamming my network”.

The value would be a possibility to create a future that would better align to their values. But the suspicion is that I have been fooled into something and am now fooling them just by being naive myself.

Part of the problem is that I have been tainted by my past excitement about bitcoin. It doesn’t help at all that ten years ago I was “right” , because the reputation of all things crypto is so extremely bad in their eyes, as it actually is in my eyes, too.

5 Likes

It makes no sense to put a GUI into the nodes. They are slim & mean services.

The only place is to have a node-manager with GUI that talks via RPC to the nodes providing UI on another (or same) computer to get stats etc and allow control of the nodes.

More maintenance. The node-manager now will likely be the forerunner of the GUI version of a manager for your nodes.

The nodes run as a service (behind the scenes) and while they can run in the foreground it makes more sense to have them as a service to have the set and forget environment that they are meant to operate in.

Just like the node-manager + vDash or both combined, either way this is definitely feasible and allows David’s arguments and other’s arguments to both be satisified. THe RPC mechanism built into nodes is the answer and even allows remote monitoring.

Now I just want the RPC info request to include a lot more information about the node.

At the moment though the CPU usage with RPC calls is high and so the polling rate needs to be lowish to keep overall cpu usage low.

Definitely and doubt many will use the client in the real world without a GUI and also easy integration into other programs so that for them the client is a background bit of code and the program provides its GUI as usual and the user is almost completely unaware of the client

8 Likes

Can’t really conclude if Beta testers will have a passkey to protect their reward. Presumably bitcoiners say “nachos keys nachos coins”, Assumably safers say “nachos passkey, macho pesky”. With three nachos in a row, i think that what i’m saying is, food 4 Todd.

2 Likes

I’m late to this thread, but surely a share library should cover this off. The TUI and the GUI should then only be concerned with rendering. Maybe it takes a bit more design effort, but it shouldn’t be too much more.

Edit: In fact, didn’t someone create a GUI that just called the CLI before? Something like that could do the job. Maybe something could wrap the new TUI. Maybe the community could do that, in fact.

Fwiw, I agree that running nodes needs a UI less than the apps that run on/with it though.

6 Likes

It would, but we use static libs as they are more secure and rust default It just gets messy

5 Likes

How is it going to be when then Autonatv2 in Libp2p is ready: are two nodes behind a home router able to find each other directly, or do they need a third public one to set the connection at the start?

3 Likes

Even if it doesn’t work, that 2 nodes on same device can communicate, it would probably be of little consequence once the network passes 10,000 or 50,000 nodes. Reasoning is that for your 20 nodes it will be rare that 2 need to talk to each other and even when it happens messages will route through other nodes. I guess your two nodes will end up shunning each other, but everyone else can talk to them.

I could see a problem that even in a 50K node network that someone with 2000 nodes behind the one router might have a number of such nodes. but when the network is like 1 million nodes then even that 2000 node installation might not see many at all of this.

5 Likes