Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to integrate naming services with GitTorrent? #73

Open
paulkernfeld opened this issue Feb 23, 2016 · 3 comments
Open

How to integrate naming services with GitTorrent? #73

paulkernfeld opened this issue Feb 23, 2016 · 3 comments

Comments

@paulkernfeld
Copy link

There have been a couple proposals for integrating different decentralized naming systems with GitTorrent (see #71, #72). If we go with the "namespacing" option (e.g. paulkernfeld@namecoin), how should these systems be integrated with GitTorrent?

It seems like a bad idea to integrate these libraries directly into GitTorrent for a couple reasons. First, this would bloat GitTorrent, increasing install time and complexity. Second, not all decentralized naming clients are written in Node.

So, perhaps the best option is to have GitTorrent run clients by calling out to an external process?

CC @blockstack, @xloem

@xloem
Copy link

xloem commented Feb 23, 2016

The most public energy I've found so far around storing non-financial data in mainstream blockchains has been in Node -- see for example https://github.com/blockai/blockcast .

I think the route is to create a fledgling distributed naming system library in Node that could be used by other projects as well, and to use this library with gittorrent.

It wouldn't have to provide any more implementations than we care for in the moment, but maybe somebody would want to add e.g. gnunet later for a different project, and then gittorrent could benefit.

@adlai
Copy link

adlai commented Feb 26, 2016

If the entire "namespacing" need fits within 80 bytes, then inserting it directly into OP_RETURN suffices. Blockcast is excellent for prototyping, but a finalized use-case can probably do better (at the very least, one should extend Blockcast to support dynamic fees).

@xloem
Copy link

xloem commented Feb 26, 2016

I mentioned blockcast as an example of how Node already has an active OP_RETURN ecosystem.
I think namespacing should be done in a separate Node module that can be later extended to support a variety of backends. The initial implementation doesn't matter and should be whatever backend is easiest to write the code for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants