Expansion of IPv6 Address

[darkdrgn2k]

Expand specs IPv6 to include Yggdrsail

Suggestions

Backwards compatibility

   {
     "name": "Free Geek Toronto",
     "latitude": 43.641920944151614,
     "longitude":-79.4252866754631,
     "cardinalDirection": "Omni",
     "floor": 1,
     "status": "active",
     "IPV6Address":"fcc5:480e:20d6:dd89:12e1:19f8:23b9:f6ab",
     "IPV6Yggdrasil":"fcc5:480e:20d6:dd89:12e1:19f8:23b9:f6ab",
     "dateAdded": "2018-04-19T23:52:59.804Z"
},

Little more descriptive

   {
     "name": "Free Geek Toronto",
     "latitude": 43.641920944151614,
     "longitude":-79.4252866754631,
     "cardinalDirection": "Omni",
     "floor": 1,
     "status": "active",
     "IPV6CJDNS": "fcc5:480e:20d6:dd89:12e1:19f8:23b9:f6ab",
     "IPv6Yggdrasil":"fcc5:480e:20d6:dd89:12e1:19f8:23b9:f6ab",
     "dateAdded": "2018-04-19T23:52:59.804Z"
}

Or create an array as such

   {
     "name": "Free Geek Toronto",
     "latitude": 43.641920944151614,
     "longitude":-79.4252866754631,
     "cardinalDirection": "Omni",
     "floor": 1,
     "status": "active",
     "IPV6Address": [
          "cjdns":"fcc5:480e:20d6:dd89:12e1:19f8:23b9:f6ab",
          "yggdrasil":"fcc5:480e:20d6:dd89:12e1:19f8:23b9:f6ab"
      ],
     "dateAdded": "2018-04-19T23:52:59.804Z"
}

[darkdrgn2k]

Maybe add also what type of mesh its running?

[Shrinks99]

I like the array option as it can be expanded upon in the future in a nice way that doesn't break things and is semantically neat. How much stuff breaks if we do it that way?

[darkdrgn2k]

i wouldn't worry about breaking stuff to much.. TOMESH map and some stuff i built.. thats about it.

Early on not to worried about the havoc it will cause

[benhylau]

We should do this instead, because these protocols are complex and often require more than one field to work with (e.g. cjdns past a certain version is not backward compatible):

{
  "protocols": [
    {
      "name": "cjdns",
      "attributes": {
        "version": "v16",
        "ipv6": "fcc5:480e:20d6:dd89:12e1:19f8:23b9:f6ab"
      }
    },
    {
      "name": "yggdrasil",
      "attributes": {
        "version": "v12.2",
        "ipv6": "fcc5:480e:20d6:dd89:12e1:19f8:23b9:f6ab",
        "peering": true
      }
    },
    {
      "name": "ipfs",
      "attributes": {
        "version": "v13.5",
        "id": "ipfs-id",
        "public-key": "ipfs-public-key"
      }
    }
  ]
}

The keys within each protocol is just an example, but name and attributes should be there. We can incorporate this into schema-v8.

[darkdrgn2k]

Should there be a seperate services json?

[makew0rld]

I think that would be good for actual mesh services like sites or DNS, etc. I'm not sure if Yggdrasil/CJDNS falls under that or not though. IPFS would imo, so why not those too.

[benhylau]

Should there be a seperate services json?

@darkdrgn2k I am not opposed to that. Do you think cjdns, yggdrasil, and ipfs should all be in that services json?

We also need a unique key to map between the two.

As @makeworld-the-better-one showed, it's hard to decide which goes to which json. In my mind, these are all in the services json. Whether we wanna stick that in here or another file, I am kinda split, because single file does have its advantages of being easy to parse in business logic :)

[darkdrgn2k]

We also need a unique key to map between the two.

Currently the NODE NAME is planned to be unique across the network.

I am kinda split, because single file does have its advantages of being easy to parse in business logic :)

I fear that as the network grows it may become to big.

Also what about "multicast" services, services that exist on multiple nodes (like DNS)

[makew0rld]

I fear that as the network grows it may become to big.

I agree, I think that having a separate services file is fine.

Also what about "multicast" services, services that exist on multiple nodes (like DNS)

Not sure exactly what you mean, but the file could be organized by service anyway, with potentially multiple nodes offering it.

{
	"DNS": [
		"1.1.1.1:123",
		"1.2.3.4:321"
	]
}