[kwlug-disc] Callout to CS majors/Other technically savvy klwug listers.
paul_nijjar at yahoo.ca
Fri Feb 8 14:26:39 EST 2019
On Thu, Feb 07, 2019 at 05:37:43PM -0800, Doug Moen wrote:
> The centralized model (eg, how github works) has the advantage of being
> well known, it's obvious how to set it up. The problem is that I don't
> want to pay for the servers needed to keep the CurvNet running,
> especially if it the project takes off and becomes really popular.
> Creating a business model that pays for the servers to keep running is
> also problematic. It's either advertising (collecting people's personal
> information and reselling it), or you pay for an account, which creates
> a large barrier to entry. Plus it's centralized, so if the CurvNet
> server shuts down, then everybody loses.
> I'd prefer a decentralized model. But where are the servers where the
> content is stored; who pays for those servers? How do you find content
> on the network related to your interests? How much friction is involved
> in publishing content to the network?
Why isn't github that server? Why isn't git the backend?
It sounds to me as if you want CurvNet to be some kind of repository
(a la Debian's apt repositories) or some kind of directory (a la
Yahoo! in the 1990s). Here are some blue-sky thoughts as to how you
might set up such a system for CurvNet:
- The "database" of information is a git repository. Maybe it just
points to locations where you can find interesting Curv projects.
Maybe it aggregates the code for those Curv projects into the
- You start this git repo and host it on Github. This can be thought
of as the canonical repository, where most people go to find Curv
- Say somebody wants to add an entry to the repo. That is a pull
request followed by a merge. (I wish standard git supported pull
requests.) You could also do the Linux kernel thing where you have
subordinates who do much of the project filtering and standards, and
then you periodically pull those changes into your repo.
- Oh no! You have given up on Curv and take down the repo. That is
okay. If somebody else has forked the project then there is the
chance that the Curv repo lives on.
- Oh no! There has been a big fight, and now there is a schism as to
what the repo should contain. So now there is a hard fork and
multiple repositories, similar to the way you can have multiple APT
repos in Debian.
- The frontends for CurvNet would want the ability to point at
different repos, and have some mechanism for resolving conflicting
packages. Again, I think APT has solved this problem.
- Oh no! Github does not offer free hosting for CurvNet any more. The
backend is just a git repo, so it can be hosted elsewhere. Maybe
that elsewhere is a server people pay for (at which time you have to
figure out how to incentivize this payment). Or maybe you find some
Github competitor which will host the repo for free. The end users
just (or "just") need to point their repositories to the new
- Maybe you could also allow repos to be mirrored in the same way APT
repos are mirrored. Git makes this possible, although maybe it is
not trivial to do this automatically?
The nice thing about such a setup is that it would be federated in
multiple ways. There could be many different repositories with
different package listings. There could be ways for some repos to pull
information from others. And there would be ways for repos to mirror
each other. There is no "CurvCoin" that you mine to become
unbelievably rich and/or attract VC funding, but that does not sound
like one of your goals.
This may be wholly untenable, or it may be already implemented and
available for you to use. But it sounds to me as if there are some
solutions to this problem that do not require a lot of operational
costs and do not need a blockchain.
More information about the kwlug-disc