Melvin Carvalho [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-28 📝 Original message: On Thu, 24 Jan 2019 at ...
📅 Original date posted:2019-01-28
📝 Original message:
On Thu, 24 Jan 2019 at 13:42, René Pickhardt <r.pickhardt at googlemail.com>
wrote:
> Dear Melvin,
>
> I believe the vocabulary is not consistent across implementations. For
> example if you look at c lightning there is no such command `describegraph`
> but there are the two commands `listnodes` and `listchannels` which should
> give the same information. For both I have attached a sample output at the
> end of the mail to demonstrate how the naming of the vocabulary differs.
>
> Since the data of these commands is taken from the gossip store which
> stores the gossip messages I would suggest to take the vocabulary from the
> BOLT 07 which defines the gossip messages. Also this mailinglist is for
> protocol development and the spec should be the authorative source for
> naming:
> https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
>
> There are more terms specified in other bolts which could be a basis for a
> vocabulary. I have created an overview by hand and made a Pull Request to
> the repository which has not been merged yet as it was the wish of the
> developers to have such a list to be extracted automatically.
> Still this the overview in that pull request could serve as a basis for
> such a vocabulary :
> https://github.com/lightningnetwork/lightning-rfc/pull/458
>
> Now the example outputs from c-lightning we already that there are
> differences in naming. Take the identifier for a node for example:
> * BOLT07: node_id
> * LND: pub_key
> * clightning: nodeid
>
> example outputs:
>
> lighting-cli listnodes
> {
> "nodeid":
> "02396bf51e81f8f67eaca3652271b4fe8d3f57bedb9578af711606391c5c66760e",
> "alias": "PuraSloboda",
> "color": "68f442",
> "last_timestamp": 1548200218,
> "globalfeatures": "",
> "global_features": "",
> "addresses": [
> {
> "type": "ipv4",
> "address": "144.136.223.22",
> "port": 9735
> }
> ]
> }
>
> lightning-cli listchannels
> {
> "source":
> "03bb88ccc444534da7b5b64b4f7b15e1eccb18e102db0e400d4b9cfe93763aa26d",
> "destination":
> "0272045af48b9871013753f7cce1cf82ed80b97d669ca44709e01976a67df80adc",
> "short_channel_id": "559893:1912:0",
> "public": true,
> "satoshis": 47000,
> "message_flags": 0,
> "channel_flags": 1,
> "flags": 1,
> "active": true,
> "last_update": 1548332847,
> "base_fee_millisatoshi": 1000,
> "fee_per_millionth": 1,
> "delay": 144
> }
>
> With kind regards Rene
>
This is extremely helpful, thank you!
I will go with the RFC naming then. I'm starting with Nodes and Edges and
will put together a document and demo for review. First step is to do
Nodes.
I have two questions
1. node_id -- that's basically your public key -- what types of key and
serialization is this (my guess an ecdsa pub key derived from the HD seed),
any pointers would be great
2. regarding the four address types :
- 1: ipv4; data = [4:ipv4_addr][2:port] (length 6)
- 2: ipv6; data = [16:ipv6_addr][2:port] (length 18)
- 3: Tor v2 onion service; data = [10:onion_addr][2:port] (length 12)
- version 2 onion service addresses; Encodes an 80-bit, truncated
SHA-1 hash of a 1024-bit RSA public key for the onion service (a.k.a.
Tor hidden service).
- 4: Tor v3 onion service; data = [35:onion_addr][2:port] (length 37)
- version 3 (prop224
<https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt>;)
onion service addresses; Encodes: [32:32_byte_ed25519_pubkey] ||
[2:checksum] || [1:version], where checksum = sha3(".onion checksum"
| pubkey || version)[:2].
These can be looked up in the spec. But in the semantic web we like, where
possible, to have self describing data. In particular we like URIs with a
scheme or protocol so instead of example.com we'll have http://example.com
In this context would the scheme be lightning: for all 4 address types, or
is that just for bolt11?
>
> On Thu, Jan 24, 2019 at 1:21 PM Melvin Carvalho <melvincarvalho at gmail.com>
> wrote:
>
>>
>>
>> On Mon, 21 Jan 2019 at 14:11, René Pickhardt <r.pickhardt at googlemail.com>
>> wrote:
>>
>>> Dear Melvin,
>>>
>>> have you looked into the W3C Payment Group?
>>> https://www.w3.org/TR/payment-request/ The entire field of semantic web
>>> kind of originated from W3C and they are working on a recommendation for
>>> browser vendors to enable a low level payment API.
>>>
>>> Also there is LightningJoule that builds on top of webln. While this is
>>> not an otology it goes implicitly in a similar direction (c.f.:
>>> https://github.com/wbobeirne/webln and in particular this discussion:
>>> https://github.com/wbobeirne/webln/issues/1 in which Will said that in
>>> his thoughts webln is different to the W3C Payment Group.)
>>>
>>> I am looking forward to see your progress with integrating Lightning to
>>> the semantic web!
>>>
>>> with kind regards Rene
>>>
>>
>> My first observation is these two data structures in lnd describe graph,
>> one for channels and one for nodes. These seem to be two fundamental
>> concepts in lightning.
>>
>> Channel
>>
>> {
>> "channel_id": "615605565348708353",
>> "chan_point":
>> "d8cfed73e0004fe1427d3045c5b20da0418f3cb803e8e35be48ee713aadbf56d:1",
>> "last_update": 1548330355,
>> "node1_pub":
>> "024a2e265cd66066b78a788ae615acdc84b5b0dec9efac36d7ac87513015eaf6ed",
>> "node2_pub":
>> "03e03c56bb540c36b9e77c2aea2bb6529b907ece6c1395228c05459af13d0e2a5c",
>> "capacity": "1000000",
>> "node1_policy": {
>> "time_lock_delta": 144,
>> "min_htlc": "1000",
>> "fee_base_msat": "1000",
>> "fee_rate_milli_msat": "1",
>> "disabled": false
>> },
>> "node2_policy": {
>> "time_lock_delta": 144,
>> "min_htlc": "1000",
>> "fee_base_msat": "1000",
>> "fee_rate_milli_msat": "1",
>> "disabled": false
>> }
>> }
>>
>> Node
>>
>> {
>> "last_update": 1547380072,
>> "pub_key":
>> "0200072fd301cb4a680f26d87c28b705ccd6a1d5b00f1b5efd7fe5f998f1bbb1f1",
>> "alias": "OutaSpace",
>> "addresses": [
>> {
>> "network": "tcp",
>> "addr": "46.163.78.93:9760"
>> },
>> {
>> "network": "tcp",
>> "addr": "[2a01:488:66:1000:2ea3:4e5d:0:1]:9760"
>> },
>> {
>> "network": "tcp",
>> "addr": "2dkobxxunnjatyph.onion:9760"
>> },
>> {
>> "network": "tcp",
>> "addr":
>> "nzslu33ecbokyn32teza2peiiiuye43ftom7jvnuhsxdbg3vhw7w3aqd.onion:9760"
>> }
>> ],
>> "color": "#123456"
>> },
>>
>> It would be useful to write a vocab for these and then document what they
>> mean. It would then be possible to add markup to an explorer to make it
>> self documenting.
>>
>> My first question is : are these terms consistent across different
>> implementations e.g. c-lightning, eclair ?
>>
>>
>>>
>>>
>>> On Mon, Jan 21, 2019 at 7:17 AM Melvin Carvalho <
>>> melvincarvalho at gmail.com> wrote:
>>>
>>>> Hi All
>>>>
>>>> I work on the solid project [1] and am very interested in the lightning
>>>> network.
>>>>
>>>> In particular, I am looking at trying to create an integration between
>>>> lightning (layer 2) and solid (layer 3? web layer?).
>>>>
>>>> The first step towards integration would be to port some of the
>>>> lightning concepts to the semantic web. This is done by creating an
>>>> ontology.
>>>>
>>>> Does anyone know of any existing work in this area. Alternatively,
>>>> does anyone have an interest to collaborate on an ontology?
>>>>
>>>> Best
>>>> Melvin
>>>>
>>>> [1] https://solid.mit.edu/
>>>> _______________________________________________
>>>> Lightning-dev mailing list
>>>> Lightning-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>>
>>>
>>> --
>>> https://www.rene-pickhardt.de
>>>
>>> Skype: rene.pickhardt
>>>
>>> mobile: +49 (0)176 5762 3618
>>>
>>
>
> --
> https://www.rene-pickhardt.de
>
> Skype: rene.pickhardt
>
> mobile: +49 (0)176 5762 3618
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190128/0f8993e4/attachment-0001.html>;
📝 Original message:
On Thu, 24 Jan 2019 at 13:42, René Pickhardt <r.pickhardt at googlemail.com>
wrote:
> Dear Melvin,
>
> I believe the vocabulary is not consistent across implementations. For
> example if you look at c lightning there is no such command `describegraph`
> but there are the two commands `listnodes` and `listchannels` which should
> give the same information. For both I have attached a sample output at the
> end of the mail to demonstrate how the naming of the vocabulary differs.
>
> Since the data of these commands is taken from the gossip store which
> stores the gossip messages I would suggest to take the vocabulary from the
> BOLT 07 which defines the gossip messages. Also this mailinglist is for
> protocol development and the spec should be the authorative source for
> naming:
> https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
>
> There are more terms specified in other bolts which could be a basis for a
> vocabulary. I have created an overview by hand and made a Pull Request to
> the repository which has not been merged yet as it was the wish of the
> developers to have such a list to be extracted automatically.
> Still this the overview in that pull request could serve as a basis for
> such a vocabulary :
> https://github.com/lightningnetwork/lightning-rfc/pull/458
>
> Now the example outputs from c-lightning we already that there are
> differences in naming. Take the identifier for a node for example:
> * BOLT07: node_id
> * LND: pub_key
> * clightning: nodeid
>
> example outputs:
>
> lighting-cli listnodes
> {
> "nodeid":
> "02396bf51e81f8f67eaca3652271b4fe8d3f57bedb9578af711606391c5c66760e",
> "alias": "PuraSloboda",
> "color": "68f442",
> "last_timestamp": 1548200218,
> "globalfeatures": "",
> "global_features": "",
> "addresses": [
> {
> "type": "ipv4",
> "address": "144.136.223.22",
> "port": 9735
> }
> ]
> }
>
> lightning-cli listchannels
> {
> "source":
> "03bb88ccc444534da7b5b64b4f7b15e1eccb18e102db0e400d4b9cfe93763aa26d",
> "destination":
> "0272045af48b9871013753f7cce1cf82ed80b97d669ca44709e01976a67df80adc",
> "short_channel_id": "559893:1912:0",
> "public": true,
> "satoshis": 47000,
> "message_flags": 0,
> "channel_flags": 1,
> "flags": 1,
> "active": true,
> "last_update": 1548332847,
> "base_fee_millisatoshi": 1000,
> "fee_per_millionth": 1,
> "delay": 144
> }
>
> With kind regards Rene
>
This is extremely helpful, thank you!
I will go with the RFC naming then. I'm starting with Nodes and Edges and
will put together a document and demo for review. First step is to do
Nodes.
I have two questions
1. node_id -- that's basically your public key -- what types of key and
serialization is this (my guess an ecdsa pub key derived from the HD seed),
any pointers would be great
2. regarding the four address types :
- 1: ipv4; data = [4:ipv4_addr][2:port] (length 6)
- 2: ipv6; data = [16:ipv6_addr][2:port] (length 18)
- 3: Tor v2 onion service; data = [10:onion_addr][2:port] (length 12)
- version 2 onion service addresses; Encodes an 80-bit, truncated
SHA-1 hash of a 1024-bit RSA public key for the onion service (a.k.a.
Tor hidden service).
- 4: Tor v3 onion service; data = [35:onion_addr][2:port] (length 37)
- version 3 (prop224
<https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt>;)
onion service addresses; Encodes: [32:32_byte_ed25519_pubkey] ||
[2:checksum] || [1:version], where checksum = sha3(".onion checksum"
| pubkey || version)[:2].
These can be looked up in the spec. But in the semantic web we like, where
possible, to have self describing data. In particular we like URIs with a
scheme or protocol so instead of example.com we'll have http://example.com
In this context would the scheme be lightning: for all 4 address types, or
is that just for bolt11?
>
> On Thu, Jan 24, 2019 at 1:21 PM Melvin Carvalho <melvincarvalho at gmail.com>
> wrote:
>
>>
>>
>> On Mon, 21 Jan 2019 at 14:11, René Pickhardt <r.pickhardt at googlemail.com>
>> wrote:
>>
>>> Dear Melvin,
>>>
>>> have you looked into the W3C Payment Group?
>>> https://www.w3.org/TR/payment-request/ The entire field of semantic web
>>> kind of originated from W3C and they are working on a recommendation for
>>> browser vendors to enable a low level payment API.
>>>
>>> Also there is LightningJoule that builds on top of webln. While this is
>>> not an otology it goes implicitly in a similar direction (c.f.:
>>> https://github.com/wbobeirne/webln and in particular this discussion:
>>> https://github.com/wbobeirne/webln/issues/1 in which Will said that in
>>> his thoughts webln is different to the W3C Payment Group.)
>>>
>>> I am looking forward to see your progress with integrating Lightning to
>>> the semantic web!
>>>
>>> with kind regards Rene
>>>
>>
>> My first observation is these two data structures in lnd describe graph,
>> one for channels and one for nodes. These seem to be two fundamental
>> concepts in lightning.
>>
>> Channel
>>
>> {
>> "channel_id": "615605565348708353",
>> "chan_point":
>> "d8cfed73e0004fe1427d3045c5b20da0418f3cb803e8e35be48ee713aadbf56d:1",
>> "last_update": 1548330355,
>> "node1_pub":
>> "024a2e265cd66066b78a788ae615acdc84b5b0dec9efac36d7ac87513015eaf6ed",
>> "node2_pub":
>> "03e03c56bb540c36b9e77c2aea2bb6529b907ece6c1395228c05459af13d0e2a5c",
>> "capacity": "1000000",
>> "node1_policy": {
>> "time_lock_delta": 144,
>> "min_htlc": "1000",
>> "fee_base_msat": "1000",
>> "fee_rate_milli_msat": "1",
>> "disabled": false
>> },
>> "node2_policy": {
>> "time_lock_delta": 144,
>> "min_htlc": "1000",
>> "fee_base_msat": "1000",
>> "fee_rate_milli_msat": "1",
>> "disabled": false
>> }
>> }
>>
>> Node
>>
>> {
>> "last_update": 1547380072,
>> "pub_key":
>> "0200072fd301cb4a680f26d87c28b705ccd6a1d5b00f1b5efd7fe5f998f1bbb1f1",
>> "alias": "OutaSpace",
>> "addresses": [
>> {
>> "network": "tcp",
>> "addr": "46.163.78.93:9760"
>> },
>> {
>> "network": "tcp",
>> "addr": "[2a01:488:66:1000:2ea3:4e5d:0:1]:9760"
>> },
>> {
>> "network": "tcp",
>> "addr": "2dkobxxunnjatyph.onion:9760"
>> },
>> {
>> "network": "tcp",
>> "addr":
>> "nzslu33ecbokyn32teza2peiiiuye43ftom7jvnuhsxdbg3vhw7w3aqd.onion:9760"
>> }
>> ],
>> "color": "#123456"
>> },
>>
>> It would be useful to write a vocab for these and then document what they
>> mean. It would then be possible to add markup to an explorer to make it
>> self documenting.
>>
>> My first question is : are these terms consistent across different
>> implementations e.g. c-lightning, eclair ?
>>
>>
>>>
>>>
>>> On Mon, Jan 21, 2019 at 7:17 AM Melvin Carvalho <
>>> melvincarvalho at gmail.com> wrote:
>>>
>>>> Hi All
>>>>
>>>> I work on the solid project [1] and am very interested in the lightning
>>>> network.
>>>>
>>>> In particular, I am looking at trying to create an integration between
>>>> lightning (layer 2) and solid (layer 3? web layer?).
>>>>
>>>> The first step towards integration would be to port some of the
>>>> lightning concepts to the semantic web. This is done by creating an
>>>> ontology.
>>>>
>>>> Does anyone know of any existing work in this area. Alternatively,
>>>> does anyone have an interest to collaborate on an ontology?
>>>>
>>>> Best
>>>> Melvin
>>>>
>>>> [1] https://solid.mit.edu/
>>>> _______________________________________________
>>>> Lightning-dev mailing list
>>>> Lightning-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>>
>>>
>>> --
>>> https://www.rene-pickhardt.de
>>>
>>> Skype: rene.pickhardt
>>>
>>> mobile: +49 (0)176 5762 3618
>>>
>>
>
> --
> https://www.rene-pickhardt.de
>
> Skype: rene.pickhardt
>
> mobile: +49 (0)176 5762 3618
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190128/0f8993e4/attachment-0001.html>;