From melvincarvalho at gmail.com Mon Jan 28 06:13:25 2019 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Mon, 28 Jan 2019 07:13:25 +0100 Subject: [Lightning-dev] Lightning and the semantic web In-Reply-To: References: Message-ID: On Thu, 24 Jan 2019 at 13:42, Ren? Pickhardt 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 ) 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 > wrote: > >> >> >> On Mon, 21 Jan 2019 at 14:11, Ren? Pickhardt >> 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: