rfc: Merged supernodes

[AiyionPrime]

Currently in our multidomainsetup supernodes exist 15 (domain amount) times in our setup.
This looks a little weird in gravity-view but furthermore becomes unusable in normal map mode.

Especially when a supernode is emitting a location, all 15 instances of the same machine are stacked above aech other and make it a random game which domain is on top and clickable.

This is no easy task imo, as the current representation lacks either something like a merged view of all domains (ffnord/mesh-announce#73),
or an identifier of the machine, that's the same across its announced domains.

This could be based on @genofires efforts regarding the machine-id (ffnord/mesh-announce#37), as this is primarily a supernode problem, which more than often come with systemd these days.

Is your feature request related to a problem?

The part, where supernodes are stacked on top of each other in the normal map is irritating.

Describe the solution you'd like

For now I only want to extend the discussion in hackint#gluon earlier this day.

Describe alternatives you've considered

An alternative could be to destack overlapping nodes on the normal map by something similar to the graph view, where nodes won't sit on top each other.

Additional context

14:02 <xaver_> aiyion: what is missing for multi domain?
14:04 xaver_: Either there's wrong documentation and gluon determines the primary domain in a different way;
14:05 or the documentation is on point, which would imply potentially wrong usage of luas tables;
14:06 which does work for gluon apparently, but does not necessarily for anything, that uses a different parser, that is standard conform.
14:06 <xaver_> there is no documentation (public)
14:07 ? I provided a link to said documentation?
14:07 or which one are you referring to?
14:07 <xaver_> meshviewer
14:08 ah, sorry, was talking about gluon.
14:08 the meshviewer part was just for hexa who oredered a related feature.
14:08 <xaver_> I think we use the current multi domain setup in ffrgb & processing the data is in yanic
14:08 <xaver_> ah ok
14:08 meshviewer is not lacking anything except tsys :D
14:09 <xaver_> tsys?
14:09 meshviewer master does not provide primary_domain_code yet.
14:09 fuck.
14:09 <xaver_> use develop
14:09 *mesh-announce.
14:09 <xaver_> master branch is more or (less) outdated
14:10 i did not intend to talk about meshviewer in the last thre hours;
14:11 imho meshviewer lacks support of supernodes as one entity,
14:11 though I'm not sure how I'd implement that yet.
14:11 <xaver_> i saw the highlight from 9 march
14:11 Yep, now I got you.
14:11 forget what I wrote before imho ;)
14:13 <xaver_> I open irc maybe once per month. i like irc, but most channels are dead and moved to other services.
14:13 furthermore I think supernodes should be shown with square on the normal map as well and not just in the gravity-view.
14:14 true; I don't have strong feelings about irc, its just another protocol I wrapped in weechat, and I like that #hackint does not canstantly try to sell my data :)
14:18 <xaver_> we have no super nodes and no gws on the map. In general map and structure view are 2 completely different techniques with different features. The reason links are only colored with both ends in mesh view.
14:22 --> nrb ([email protected]) has joined #gluon
14:29 mhm
14:30 I think it'd be rather nice for (other) communities to have their supernodes on the map to reduce their abstractness for users.

[xf-]

There is no solution at the moment, except move coordinates a little bit. We nothing inside of leaflet that supports such a behavior.

Maybe you can add a plugin to your instance
https://leafletjs.com/plugins.html#clusteringdecluttering

• Overlapping Marker Spiderfier sounds perfect, but last commit to code is over 8 year
• Leaflet.FeatureGroup.SubGroup maybe

[belzebub40k]

Probably it is easier to solve this on the respondd side. For our node map i solved it by introducing a pseudo Domain for all servers. I don't know if this is already possible with implementations like mesh-announce. We are using the not yet merged respondd implementation of yanic.

The yanic respondd config looks like this.

data_interval = "1m"

batman = [ "bat0", "bat1", ... ]

[[listen]]
address   = "ff02::2:1001"
interface = "wg0"

[[listen]]
address   = "ff02::2:1001"
interface = "vpn0"
port      = 1001

[[listen]]
address   = "ff02::2:1001"
interface = "vpn1"
port      = 1001
....

[defaults]
node_id  = ""
hostname = ""
site_code = "ffmwu"
domain_code = "servers"
vpn = true
interfaces_traffic = [ "eth0" ]
interfaces_address = [ "loopback" ]

The process listens on all mesh interfaces and on a direct Wireguard connection to the map server to make it mesh independent

As a result the gateways are shown only once on the map with all connected nodes.

Example: https://map.freifunk-mwu.de/#!/de/map/4766f18e7601