search

Podcastindex-org / podcast-namespace

A wholistic rss namespace for podcasting
Creative Commons Zero v1.0 Universal
388 stars 116 forks source link

<podcast:valueRecipient> Support for private nodes and channels (routing hints) #203

Open dellagustin opened 3 years ago

dellagustin commented 3 years ago

Nodes that wish to remain private will create private channels with other nodes. Without knowledge of this channels, sender nodes would not be able to find a route to the destination, in order to send a payment.

To allow podcasters to use private channels to receive payments, we also must accommodate routing hints in the valueRecipient.

References

dellagustin commented 3 years ago

@daveajones , It is becoming increasingly hard to keep the valueRecipient tag generic. Both custom records and routing hints are concepts that are specific to the lightning network.

I see a few solutions here:

  1. a protocol aware tag (i.e. valueRecipientLightning), with specific attributes (customKey, customValue, routingHints)
  2. keep it generic and add a addressSupplement attribute, which would be a string, and have all the values encoded in a protocol specific way (i.e. for lightning it could be a json containing custom records, routing hints, or anything else we need, in a format we specify) - this would keep the address attribute cleaner
  3. encode everything we need in the address.

I currently prefer option 1. I know we are striving to keep the namespace generic, but I don't see a lot of benefit on it being generic in this case. For applications trying to parse it, they can just ignore what they do not know. For applications trying to produce it, they will need specific code for specific protocols anyway. The advantage of having a protocol aware namespace is that the result is more human readable.

Any thoughts?

P.S.: Man, this is hot namespace talk...

Evanfeenstra commented 3 years ago

I prefer generic approach. At sphinx.chat we are planning to just use customKey=“route_hint” and customValue=“...” to provide a route hint.

Although customKey and customValue are intended for Lightning TLV customRecords, I see no problem using them for other requirements (even non-Lightning related things in the future)

dellagustin commented 3 years ago

@Evanfeenstra as long as it is not ambiguous and it is a spec that every app can use, I can work with it. How do you see the format of customValue for customKey = "route_hint"?

Evanfeenstra commented 3 years ago

@dellagustin Well i guess that could be stringified JSON. In our case we encourage zero fees for these private channels, so the simplest form can be “PUBKEY:CHAN_ID”. It would be pretty easy to support either format anyway

dellagustin commented 3 years ago

"PUBKEY:CHAN_ID" seems ok, it can be expanded in case there are multiple entries, the generalization could be "PUBKEY1:CHAN_ID1:FEE_BASE1:FEE_PROPORTIONAL1:CLTV_EXP_DELTA1;PUBKEY2:CHAN_ID2:FEE_BASE2:FEE_PROPORTIONAL2:CLTV_EXP_DELTA2;...".

That is easy enough to parse. I like JSON, but it would look nasty escaped and dumped into a xml attribute. Not very human readable.

When cltv_expiry_delta is not provided, what is the recommended default? Is it ok to omit it? I have zero experience with this part.

Evanfeenstra commented 3 years ago

Yes that is much more human readable and writable then stringified JSON!

cltv_expiry_delta can default to 144 (thats the default in LND). And the fees can default to 0 of course