📅 Original date posted:2021-04-21
📝 Original message:Thanks Prayank. I think the next step for both of these proposals is to
define an API. I thought about including that in the BIPs and decided it
wasn't necessary yet to get the ideas across initially. Maybe when the APIs
are defined they could go into the BIP, but it's probably better to have in
a different document. I also agree with you on Tor.
As far as whether this should be a BIP or not, I wondered that same
question. I think the BIP format is well defined and understood so I used
it for this and the other BIPs that I'm currently working on like the
incentivized moderation protocol which is mentioned in this BIP. There are
a number of "Application" BIPs, which is why I decided it made sense.
However, if it's decided there's a better format for these BIPs I'm open to
it.
Regards,
Chris
On Tue, Apr 20, 2021 at 9:26 PM Prayank <prayank at tutanota.de> wrote:
> Hello Christopher,
>
> Decentralized storage as an idea looks interesting. I am researching about
> similar things for one of my Bitcoin project. Although an implementation or
> proof of concept code in the BIP would have been better. Also since this
> involves LN, maybe it can just be a LN project instead of BIP? Not the best
> person to comment on what can be a BIP.
>
> Few links that you may find interesting:
>
> https://github.com/bkiac/tarnhelm
>
> https://github.com/ElementsProject/filebazaar
>
> The kind of decentralized storage that I think can be helpful for Bitcoin
> projects:
>
> 1.Uses torrents for files and communication required (with Tor)
>
> 2.Easy to use API to save, read, edit etc. something in a Bitcoin project
> using torrents. Only involve lightning network and payments when spamming
> can be an issue. For example: If a developer wants users to pay for every
> P2P offer they create using a DEX protocol.
>
> Projects that are exploring such options:
> https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/415
>
> --
> Prayank
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210421/3bf15d90/attachment-0001.html>;
Christopher Gilliard [ARCHIVE] /
npub1qm…0hwnt
2023-06-07 22:51:59
in reply to nevent1q…udqd
Author Public Key
npub1qmsejphez6np2my9fu40kj9en68d5fa3s7ap4ul7eh9aeuljusgs50hwntSeen on
wss://relay.nostr.bandPublished at
2023-06-07 22:51:59Event JSON
{
"id": "48e076b5d843f366342fe29ee4922874addf8416cb7ced63f87dd23430b6a79e",
"pubkey": "06e19906f916a6156c854f2afb48b99e8eda27b187ba1af3fecdcbdcf3f2e411",
"created_at": 1686178319,
"kind": 1,
"tags": [
[
"e",
"9ece245b5da71aeaa32b348638d6732d1571e455f3de336de19bd85727c41635",
"",
"root"
],
[
"e",
"0d96d5a2e072596f0f224996e54d99e0cc8c0959eed2f11d6acf581a494952cf",
"",
"reply"
],
[
"p",
"339a4dd213c9ce6fb7143bcbd13868ec03a78b2af67b0465c7cf83164bc01fa1"
]
],
"content": "📅 Original date posted:2021-04-21\n📝 Original message:Thanks Prayank. I think the next step for both of these proposals is to\ndefine an API. I thought about including that in the BIPs and decided it\nwasn't necessary yet to get the ideas across initially. Maybe when the APIs\nare defined they could go into the BIP, but it's probably better to have in\na different document. I also agree with you on Tor.\n\nAs far as whether this should be a BIP or not, I wondered that same\nquestion. I think the BIP format is well defined and understood so I used\nit for this and the other BIPs that I'm currently working on like the\nincentivized moderation protocol which is mentioned in this BIP. There are\na number of \"Application\" BIPs, which is why I decided it made sense.\nHowever, if it's decided there's a better format for these BIPs I'm open to\nit.\n\nRegards,\nChris\n\n\n\nOn Tue, Apr 20, 2021 at 9:26 PM Prayank \u003cprayank at tutanota.de\u003e wrote:\n\n\u003e Hello Christopher,\n\u003e\n\u003e Decentralized storage as an idea looks interesting. I am researching about\n\u003e similar things for one of my Bitcoin project. Although an implementation or\n\u003e proof of concept code in the BIP would have been better. Also since this\n\u003e involves LN, maybe it can just be a LN project instead of BIP? Not the best\n\u003e person to comment on what can be a BIP.\n\u003e\n\u003e Few links that you may find interesting:\n\u003e\n\u003e https://github.com/bkiac/tarnhelm\n\u003e\n\u003e https://github.com/ElementsProject/filebazaar\n\u003e\n\u003e The kind of decentralized storage that I think can be helpful for Bitcoin\n\u003e projects:\n\u003e\n\u003e 1.Uses torrents for files and communication required (with Tor)\n\u003e\n\u003e 2.Easy to use API to save, read, edit etc. something in a Bitcoin project\n\u003e using torrents. Only involve lightning network and payments when spamming\n\u003e can be an issue. For example: If a developer wants users to pay for every\n\u003e P2P offer they create using a DEX protocol.\n\u003e\n\u003e Projects that are exploring such options:\n\u003e https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/415\n\u003e\n\u003e --\n\u003e Prayank\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210421/3bf15d90/attachment-0001.html\u003e",
"sig": "64a6d267b9a1c3c277148fe86b45c113c515e6106d2ffdceb1f880bc105486762888632aff38e5a37d9e454cd7e7f763b96ce3735a286f601a630b356047cd46"
}