The proposal includes adding an RFC and a feature bit to Lightning. This would allow payments for mappings that are considered important, as well as make decentralized, trusted hosting of data mappings possible. Longer paths or more queries will cost more, so paying 1 satoshi per query seems reasonable. The database could be shared among nodes for a price, where a Lightning node can offer to store data per hour and the person who wishes for redundancy can pay a Lightning invoice and provide the data. However, ZmnSCPxj raised concerns about this proposal. The attacker could invent some target audience that it pretends exists, but might not actually exist. Also, non-distributed server-client protocols for storing database information pay in reverse; the querier requests some query, the responder sends the encrypted data and the key to the encrypted data, and the querier pays the invoice and receives the preimage which is the encryption key to the encrypted data. ZmnSCPxj suggested building off the "server-client database" idea to create a special node type called an "advertiser node". Advertiser nodes have a "write" interface that lets advertisers pay to set a mapping, a "read" interface that lets audiences pay to get a mapping, and a "proof" interface that lets anyone query how much the advertiser node owns in its channels. If an advertiser node owns much funds, it probably earned that from many advertisers paying to set mappings, and audiences paying to get mappings. So if the advertising node is inventing its audience, then it will have to lock some of its own funds and not spend it, sacrificing opportunity to invest it elsewhere. However, this is strongly centralizing and thus not recommended.