Profile Creation

[darkdrgn2k]

Framework for creating groups in reference to issue #161

User interface supports both

Dialog mode

and text only mode

Each option can configure the modules as one of 4 states.

• Install (true)
• Don't Install/Skip (false)
• Ask for user input ("")
• Ask for user input unless defined as environment variable (not defined)

In issue the following profiles/groups where identified

• core
• default
• all
• meshstream
• experimental

3 Framework examples i put together are

Basic Node

    WITH_MESH_POINT=true
    WITH_WIFI_AP=""
    WITH_FIREWALL=""
    WITH_CJDNS_IPTUNNEL=true
    WITH_IPFS=false
    WITH_PROMETHEUS_NODE_EXPORTER=true
    WITH_PROMETHEUS_SERVER=false
    WITH_GRAFANA=false
    WITH_EXTRA_TOOLS=""
    WITH_WATCHDOG=""
    WITH_YRD=""
    WITH_SSB=false
    WITH_SSB_WEB=false
    WITH_IPFS_PI_STREAM=false

PI Stream (or Mesh Stream)

    WITH_MESH_POINT=true
    WITH_WIFI_AP=true
    WITH_FIREWALL=""
    WITH_CJDNS_IPTUNNEL=true
    WITH_IPFS=true
    WITH_PROMETHEUS_NODE_EXPORTER=""
    WITH_PROMETHEUS_SERVER=false
    WITH_GRAFANA=false
    WITH_EXTRA_TOOLS=""
    WITH_WATCHDOG=""
    WITH_YRD=""
    WITH_SSB=true
    WITH_SSB_WEB=true
    WITH_IPFS_PI_STREAM=true

And Custom

ask everything unless its set as environment variable
(no settings at all)

Question

1. What are the profiles/groups called
2. What modules are included in them

Todo:
Once profiles are established we can do an environmental variable to set this like we do the modules

[benhylau]

I think Basic node should be:

WITH_MESH_POINT=true
WITH_WIFI_AP=true
WITH_FIREWALL=true
WITH_CJDNS_IPTUNNEL=true
WITH_PROMETHEUS_NODE_EXPORTER=true
WITH_EXTRA_TOOLS=true
WITH_WATCHDOG=true
WITH_YRD=true

IPFS node should add:

WITH_IPFS=true

Monitor node should add:

WITH_PROMETHEUS_NODE_EXPORTER=true
WITH_PROMETHEUS_SERVER=true
WITH_GRAFANA=true

SSB node should add the SSB stuff.

Perhaps rename Pi Stream to Camera node?

Delete the option that prompts for user input, except for Custom. I think we can make all these decisions for users that don't choose Custom.

[darkdrgn2k]

Delete the option that prompts for user input, except for Custom. I think we can make all these decisions for users that don't choose Custom.

Perhaps it should be an option since there are some modules which are in depended of the profile.

IE: adhoc vs wifi or Yagdrissil

[makew0rld]

I like @benhylau's profiles, but I think it might be nice to allow them to stack. For example, a user could choose to install Basic Node, along with IPFS Node. Not just install IPFS Node which also installs all the Basic Node stuff. This way it's more like lists of packages, which can be installed or not as the user wishes. But I agree with @darkdrgn2k that there should be some choice still, for the things not covered by any pkg list. So for example, if the user selects Basic Node
and IPFS Node, it won't ask them about any of the stuff in Monitor Node, because they purposefully choose not to have that, but it would ask the user about yggdrasil or adhoc, since those aren't covered by any list. Does that make sense, or am I being crazy?

[darkdrgn2k]

Well basic node will probably be a prerequisite for all the packages. (bare bones)So thats probably a bad example.

I would have a "custom" node that will ask you for each individual item to install or not (like we have now).

I think the profiles are to spin up a quick IPFS | SSB | PI STREAM node without thinking much.

thoughts?

[makew0rld]

I see your point. I suppose the decision about whether there should be any user input at all once they select a profile is about whether we want the install to be one button press or not. I don't think we're at that point yet, I think it's still a good idea to ask about some things as @darkdrgn2k mentioned.

[benhylau]

I see it this way:

First time user

• Quickest way to get things going
• No ambiguity, they should be able to set this up without going to our chat

Experienced user

• Custom profile
• Come to our chat and understand ad-hoc vs. mesh-point

@darkdrgn2k and @makeworld-the-better-one want something in the middle. I am not sure how many people are in the middle, and I am afraid by not serving the first time user, our feature loses its most important purpose imo.

[makew0rld]

I understand what you mean, but we're not at a consumer product point where we want it to be super easy for users. If they don't understand they difference between ad-hoc and mesh-point they are going to need to come to our chat anyway when their nodes don't connect. It's a prototype, and I think making a one step install might over-simplify choices that should be more thought out by the user.

[darkdrgn2k]

but we're not at a consumer product point where we want it to be super easy for users

I think we are. There is increasingly more people coming through our "doors" looking at the stack for a number of reasons. Although I warn them not to install everything, they do anyway.

This is a good way to limit what they install while still leaving it wide open to anyone else who wants to build a custom node.

[benhylau]

I think it is more about a reference set up that will always 100% work. Currently we don't have that. Depending on what you select in one of many options, the result is different. Think of it this way... if someone comes to the room saying it doesn't work, we ask:

• What hardware?
• Did you select ad hoc?
• Did you choose the same mesh name?

Making this first steps as:

• Did you use exactly the same reference hardware and select Basic Node?

That's much easier to come to an established understanding.

Architecturally, WITH_* flags should be handled the same. Having fine grained understanding of WITH_MESH_POINT is not a Profile candidate, it is a later decision, makes software less maintainable long term. If it is more like "WPA-PSK vs. WPA-EAP", and is a "runtime decision", then it should be implemented as so. Trying to dig into the meaning of a flag and building a feature based on that meaning generally makes code more difficult to understand, and new people harder to get involved.

[darkdrgn2k]

@darkdrgn2k and @makeworld-the-better-one want something in the middle

I think one click install is the best way of doing it,

But I suggest that maybe SOME options are independent of the profile.
Ie: WITH_EXTRA_TOOLS

But maybe i can come to a happy compromise.
Maybe we can first have the option of "Basic" or "Expert"

Then

• Basic mode defaults to false for everything that we dont define
• Expert mode defaults to to ask questions

[benhylau]

Maybe we can first have the option of "Basic" or "Expert"

I think having a mode on top of a profile is really complicating things. The mapping from:

Expert -> Questions

Is also super counter-intuitive.

[darkdrgn2k]

Did you use exactly the same reference hardware and select Basic Node?

Problem is that the current reference hardware is broken - the TPLINK V1 noted in the readme is dead
Perhaps we should correct that.

But about 60% of the people to come through the chat fail question #1 - What hardware, because they SKIP the part about needing a dongle to mesh.

But i agrea, perhaps the decision between adhoc and meshpoint was NOT the best example.

One thing we may want to consider is adding a profile for a "dongle less" setup where we use the onboard wifi with ad-hoc. This would open the doors up to more people, but requires more thought as we would loose the wifi access point which is the primary way into the device currently.

[darkdrgn2k]

think having a mode on top of a profile is really complicating things

All it would do is replace "" with "false" if selected. This would limit the complexity quite a bit, but i do agree another question may complicate things.

Anyway reading over the thread, @benhylau seems to feel strongly about "less question" which has its benefits.

Seeing how we would not loose any functionality (as the custom profile would STILL allow you to fine tune it as you can now) i say we keep it simple (no additional questions) and if needed circle back to it if we get any feedback.

[benhylau]

I wonder if an alternative UI is possible where there is a constant screen representing all the flags and their state:

Feature	State
WITH_MESH_POINT	true
WITH_WIFI_AP	true
WITH_FIREWALL	true
. . .	. . .
WITH_GRAFANA	true

Then you scroll between the Profile options of:

Basic node
IPFS node
Monitor node
SSB node
Yggdrasil node
Custom

And the flags change accordingly. For any selection, you can move cursor to table, and alter any of the flag states. Once anything is mismatched, you will automatically be in a Custom Profile. If you manually change things to match a particular Profile, then that gets highlighted again.

This may be very difficult to implement. Just throwing the idea out, it may not be worth it for the use of this repo.

[benhylau]

One thing we may want to consider is adding a profile for a "dongle less" setup where we use the onboard wifi with ad-hoc.

I agree that switching to a setup that requires only a Raspberry Pi and nothing else, as baseline, may be a really good way to make this more accessible. Maybe mesh-point is not a "Basic node" configuration at all.

[makew0rld]

I think it is more about a reference set up that will always 100% work. Currently we don't have that.

That makes sense to me, but my initial worry was just that we might make things worse for new users, because we gloss over important design decisions with one click profiles. But I see their advantages as well. I like the install idea @benhylau proposed, it doesn't gloss over all the important settings that exist, but it also makes it easy to have defaults. I wonder how difficult it would be to implement, @darkdrgn2k. I also agree with the idea of a ad-hoc setup by default. Could that be included here? Or is it something for another day?

[darkdrgn2k]

two issues are

-how do you access the pi if you don't have wifi ap

-adhoc on rpi only supports 20mhz. so either we default all adhoc to 20 hmz then it will. mesh with other dongles to... or we remove the 40hmz option upon install but won't mesh with other adhoc modes

I always thought we should drop 40mhz because of noise in t.o

[makew0rld]

I support everything being dropped to 20 mhz, but I don't know enough about the cons of that.

[darkdrgn2k]

@makeworld-the-better-one

TL;DR Summary

20MHz

• Less Noise = More stable
• Less throughput
• More supported devices

40Mhz

• More throughput available
• More noise - Possibly weaker link

Issues

• If we switch mesh point old versions will not mesh with new versions.

Longer description

2.4 GHz Wifi is made up of 11 channels spaced 5Mhz apart ~(total spectrum 50 MHz)

Because we use define channels by "Center frequencies" (that is the frequency that is in the middle of the band) There is another ~10MHz on each end of the spectrum. (As an example Channel 1 is known as 2412Mhz, because that's the middle. It actually starts at 2401Mhz. ) That brings the total spectrum up to ~ 65 MHz.

Standard WIFI channel is 20MHz, this means it covers about 4-5 channels. (basically 2 channels in each direction of the selected channel) Any overlapping channels make NOISE for the channels they overlap.

In a "Best case" scenario you dont want channels to be overlapping. This is why there they say to run wifi only on 1 6 11 because then they dont overlap. If they overlap then its just noise. This means there are only 3 non-overlapping usable channels on 2.4 Ghz. (65 Mhz /20Mhz=~3 + a bit of space for separating channels to prevent noise.)

40MHz is a little more difficult. First you can only fit ONE 40mhz channel in 2.4 Ghz without overlapping.

Current model

Current model we use 1 x 20MHz channel for Access point (channel 1) and 1 x 40Mhz channel for Mesh Point (and as such AdHoc etc)

• This takes over the whole spectrum.
• Any other devices on channels 2, 3 running 20MHz create nose for the access point
• Any other devices on channels 1,2,3,4,5,6,7,8,9 running 40Mhz create nose for the access point
• Any devices running on channels 2,3,4,5,6,7,8,9,10,11 running 20MHz create noise for the mesh
• Any devices running on channels 2,3,4,5,6,7,8,9,10 running 40Mhz create noise for the mesh.

/_\ if there is allot of devices on any other channels/bands that we use we get allot more noise.

[makew0rld]

The two main cons I see are

Less throughput

If we switch mesh point old versions will not mesh with new versions.

I think the latter can be disregarded, as this a prototype and breaking changes with new versions should be expected. Could you expand on the former? Will 20mhz actually have a noticeable difference for the applications we use and testing we do?

Also, to go back to an original issue:

how do you access the pi if you don't have wifi ap

Maybe our docs could encourage connecting the pi to your router with an ethernet cable, or using a TTY cable? Like just something to make it clear how to access it, and how an AP won't be available if they use ad-hoc.

[darkdrgn2k]

Here is what i have so far:

I left the following optional on all profiles

WITH_MESH_POINT="" - Maybe they want adhoc instead, or they dont have a dongle
WITH_WIFI_AP="" - Easier at the moment to leave it like this so the script automatically selects if there even is a wifi onboard

    "A")
        echo "Basic node"
        WITH_YGGDRASIL=true
        WITH_MESH_POINT=""
        WITH_WIFI_AP=""
        WITH_FIREWALL=true
        WITH_CJDNS_IPTUNNEL=true
        WITH_IPFS=false
        WITH_PROMETHEUS_NODE_EXPORTER=true
        WITH_EXTRA_TOOLS=true
        WITH_WATCHDOG=true
        WITH_YRD=true
        WITH_PROMETHEUS_SERVER=false
        WITH_GRAFANA=false
        WITH_SSB=false
        WITH_SSB_WEB=false
        WITH_IPFS_PI_STREAM=false
    ;;
    "B")
        echo "Basic IPFS node"
        WITH_YGGDRASIL=true
        WITH_MESH_POINT=""
        WITH_WIFI_AP=""
        WITH_FIREWALL=true
        WITH_CJDNS_IPTUNNEL=true
        WITH_IPFS=true
        WITH_PROMETHEUS_NODE_EXPORTER=true
        WITH_EXTRA_TOOLS=true
        WITH_WATCHDOG=true
        WITH_YRD=true
        WITH_PROMETHEUS_SERVER=false
        WITH_GRAFANA=false
        WITH_SSB=false
        WITH_SSB_WEB=false
        WITH_IPFS_PI_STREAM=false
    ;;
    "C")
        echo "Monitor Node"
       echo "Monitor Node"
        WITH_YGGDRASIL=true
        WITH_MESH_POINT=""
        WITH_WIFI_AP=""
        WITH_FIREWALL=true
        WITH_CJDNS_IPTUNNEL=true
        WITH_IPFS=false
        WITH_PROMETHEUS_NODE_EXPORTER=true
        WITH_EXTRA_TOOLS=true
        WITH_WATCHDOG=true
        WITH_YRD=true
        WITH_PROMETHEUS_SERVER=true
        WITH_GRAFANA=true
        WITH_SSB=false
        WITH_SSB_WEB=false
        WITH_IPFS_PI_STREAM=false
  "D")
        echo "SSB Node"
        WITH_YGGDRASIL=true
        WITH_MESH_POINT=""
        WITH_WIFI_AP=""
        WITH_FIREWALL=true
        WITH_CJDNS_IPTUNNEL=true
        WITH_IPFS=false
        WITH_PROMETHEUS_NODE_EXPORTER=true
        WITH_EXTRA_TOOLS=true
        WITH_WATCHDOG=true
        WITH_YRD=true
        WITH_PROMETHEUS_SERVER=false
        WITH_GRAFANA=false
        WITH_SSB=true
        WITH_SSB_PATCHFOO=true
        WITH_IPFS_PI_STREAM=false
   ;;
    "E")
        echo "IPFS Camera Node"
        WITH_YGGDRASIL=true
        WITH_MESH_POINT=""
        WITH_WIFI_AP=""
        WITH_FIREWALL=true
        WITH_CJDNS_IPTUNNEL=true
        WITH_IPFS=true
        WITH_PROMETHEUS_NODE_EXPORTER=true
        WITH_EXTRA_TOOLS=true
        WITH_WATCHDOG=true
        WITH_YRD=true
        WITH_PROMETHEUS_SERVER=false
        WITH_GRAFANA=false
        WITH_SSB=false
        WITH_SSB_PATCHFOO=false
        WITH_IPFS_PI_STREAM=true
    ;;

[makew0rld]

One concern: I don't think Yggdrasil should be automatically included, it should probably be a choice. Some people will only be using CJDNS and although for now CJDNS is mandatory, in the future we may see people wanting to only use Yggdrasil, meaning CJDNS would then be a choice.

I would support something like WITH_YGGDRASIL="", as you've done with mesh point and ad-hoc.

[darkdrgn2k]

I would do

which routing engine would you like..

but I think Ben would rather less questions.

anyway remeber custom is an option so you can pick. what you like like normal

[makew0rld]

which routing engine would you like..

I agree with this, but we haven't made CJDNS optional yet, see #244. For now I would leave Yggdrasil as optional, and in the future CJDNS will be too.

[benhylau]

I think it's okay to have both installed for now. Asking which routing engine is not really a question that most first time user have enough context to answer.

I think the profiles look fine.

[makew0rld]

Will there be performances issues with double routing engines? I see your point about that being a difficult question for new users, but having both of them feels counter-intuitive to me. I don't feel strongly enough about this to be against this though, once you guys feel good about merging, I'll be glad to have profiles either way.