Below is a first, very rough draft of a proposal for a global telecommunications service facilitated by the lightning network. I'm posting here to get early eyes on the project and quick feedback from the community before continuing my efforts.

Feedback I'd appreciate would include:

I plan to continue to iterate on this and will follow up in another post with next steps for this project. I'll likely move follow up discussion to a more appropriate platform for RFC.

This paper introduces a protocol for telecommunications over the lightning network. Authentication is done through the client's lightning wallet.

A negotiated billing rate is established on connection and all subsequent packets are supplemented with some form of bitcoin collateral. Implementations may consider attaching ecash alongside each packet or may include a lightning invoice payment for example.

Many regions have poor options for internet connectivity. By providing monetary incentives we can encourage providers to deploy their services to these regions.

In the first iteration of this proposal we'll restrict our focus to communications over the 802.11 family of standards as it is supported by a wide range of devices.

I propose a client-server model.

When the client requests connection it broadcasts it's bid for bandwidth and the server responds with an ask. If the bid is higher than the ask then move on to authentication. If the rates are incompatible then the two will negotiate.

A simple method of negotiation would be for each party to either terminate communication or take an incremental step towards the midpoint. Full details for negotiation are outside the scope of this proposal.

After the parties agree on a rate, we move on to authentication [1].

Authentication occurs via ligtning wallet. Once authenticated the client pays a lightning invoice and receives ecash [2][3]. ecash will be included in all subsequent communication in a way similar to onion routing [4]. ecash is preferred for lower overhead.

The server removes the ecash from the packet and forwards appropriately. Any packet with insufficient ecash will be rejected and whatever ecash was sent with that packet will be returned.

If the server does not return the ecash from the failed send, the client should terminate the connection.

A negotiation protocol should be agreed on as part of the first implementation.

This model should take into consideration the full radio spectrum in order to support the broadest range of use cases.