You are viewing a single comment's thread from:

RE: Proposal: Funding for anyx.io API Infrastructure Recurrent Costs

in #sps • 5 years ago (edited)

But you are absolutely wrong about rivalrousness. A server providing readable data is infinitely renewable

Not infinitely, no. Only up to the point where usage of the server reaches capacity to provide an acceptable quality of service, and even before that point, performance will degrade with more users, though perhaps imperceptibly at first. Being able to sequentually renew (i.e. not "use up") is not enough as you can see from the wikipedia page on rival goods

A hammer is a durable rival good. One person's use of the hammer presents a significant barrier to others who desire to use that hammer at the same time. However, the first user does not "use up" the hammer, meaning that some rival goods can still be shared through time:

Again, I'm not talking about the information. The information itself is unquestionably a public good. A particular server (such as those proposed to paid for by this proposals) is not a public good. It has rivalrous physical resources such as processing power and bandwidth, and people compete to use those resources.

The reason that roads have historically been considered to be a quasi-public good is that it has been (and is still largely) impractical to infeasible to restrict access to most roads, making them effectively unexcludable. You aren't going to put up a toll booth on every corner, and if you try doing it on some and not others (apart from specific chokepoints such as bridges are certain limited access highways), the traffic will just move around it, making the scheme again impractical. This is somewhat becoming less the case technologically (due to automated toll transponders, automatic license plate recognition, GPS, etc.) and we are indeed starting to see more methods of exclusion such as express lanes, urban congestion zones, usage-metered registration fees, etc., making them even less of a public (or more precisely nonexcludable) good.

Anyway, back to servers. It is very practical to restrict access to servers with API keys. As I said earlier, I would support an SPS proposal to pay for servers which are restricted to limited-capacity use for developers and perhaps other categories of cost-sensitive users where there is a clear strategic reason to do so. I think that is a better use of limited resources than subsidizing profitable businesses (which experience has shown are highly prone to use free servers if they are available), opening the general floodgates, and discouraging (via a carrot, at least) people who can easily do so from running their own nodes (which leads to at least unnecessary centralization and fragility).

5 years ago in #sps by
$0.00
    Reply 8
    Sort:  
  • Trending
    • [-]
     5 years ago (edited) 

    Did you finish reading the wikipedia page you linked?

    In contrast to the hammer,

    In contrast, non-rival goods may be consumed by one consumer without preventing simultaneous consumption by others

    Can you and I both use the API at the same time? YES!

    There's also this:

    For instance, use of public roads, the Internet, or police/law courts is non-rival up to a certain capacity, after which congestion means that each additional user decreases speed for others. For that, recent economic theory views rivalry as a continuum, not as a binary category,[4] where many goods are somewhere between the two extremes of completely rival and completely non-rival. A perfectly non-rival good can be consumed simultaneously by an unlimited number of consumers.

    Your argument against roads applies directly as a metaphor to IP banning. Its the same principle.
    Funny enough, one could make the argument that more usage of an API node increases efficiency of the access -- this is due to locality and caching behaviour. When two people access the same resource, the server only has to prepare that resource once before delivering it twice -- making it faster access for the second user. This is an anti-rivalrous property. :)

    It is very practical to restrict access to servers with API keys.

    It's also possible to blow up a road. This doesn't mean a road isn't a quasi-public good anymore, it means you changed the underlying properties and thus changed the good. If you don't use API keys on a server, its not restricting access. Sure, I could change it to be a private good, but I'm not.

    I'm willing to meet you half way here, but I'm surprised you're unwilling to move an inch. It's quite clear to me that this falls quite high on the spectrum of "public goodness" while being obviously not a puritan perfect one. But very few things are puritan perfect ones -- even a beautiful scenic view is worth shit if overcrowded or polluted. I don't think that you thinking in absolutes is a good way to approach this.

    $0.00
      Reply
      [-]
       5 years ago (edited) 

      It is very practical to restrict access to servers with API keys.

      It's also possible to blow up a road

      If you think that is a reasonable argument then it ought to be clear to anyone why I'm not meeting you "half way".

      It is clear that API servers (not APIs) are not public goods because they are easily excludable (without requiring explosives), regardless of silliness over whether a server is more like "the internet" or a hammer. To be considered a public good requires that the good be both non-rivelrous and non-excludable. API servers are trivially excludable. Therefore not a public good. End of story.

      Furthermore my opposition to unlimited free servers wide open derives mostly not from any economic definitions, but from how I've seen it have a negative effect on this particular ecosystem, as well as experience with a variety of blockchain projects. The healthiest and most robust ones have people running their own nodes, at least once their usage reaches the point when it is feasible to do so.

      So, like I said, I think there is good that can come from making easy and cheap or free access to API servers available to small developers, just not wide open broadly to everyone on the internet who wants to use it.

      That is my position on this proposal or ones like it.

      $0.00
        Reply
        [-]
         5 years ago (edited) 

        It was an exaggeration, and sadly you've latched on to that rather than actually address my point. A better example could have been parking a truck in front of your garage door.

        Just because something can be changed to become excludable, does not mean that it is therefore always excludable. Just because I could in the future gate a public road creating a private road, doesn't mean that that public road road is right now excludable.

        There's no "end of story" here unless you are a puritan for public goods, which is completely ideological as one can trivially concoct ways to have excludability in just about anything. That is just silly, pedantic, and simply detracts from the point that something can be provided in a non-exclusionary way to be a quasi-public good.

        Your other point -- a subjective viewpoint that public API's are a detriment or have a negative impact -- well, we will just have to agree to disagree here.

        $0.00
          Reply
          [-]
           5 years ago (edited) 

          Your arguments are getting increasingly ridiculous. A garage is not a public good by any defintion, so the fact that one can exclude use of it by parking a truck in front of it (or with a door) does not mean anything at all.

          The definition is non-excludable is that it isn't possible (or if you want to go with a sliding definition, less practical or feasible) to limit access.

          That's just not the case for a server.

          the point that something can be provided in a non-exclusionary way to be a quasi-public good.

          No that's exactly backwards! Just about anything can be provided in a non-exclusionary way if someone willing to pay to make it freely available.

          The reason the category of public goods is important is because these are goods where it isn't practical or feasible to control access, therefore they must be funded by some sort of collective or public funding or they will not be provided or will be under-provided. This is a market failure.

          Again, that isn't the case for servers, and especially not for nodes on a p2p cryptocurrency where you can get all the access you want or need by running your own. There is no market failure. (Except, arguably in the case of smaller developers, experimental use, etc. where the cost and difficulty of running a node might be a significant barrier).

          I also get that running a Steem API node is a pain in the ass, so the barrier is somewhat higher than it might be. Nevertheless the barrier is not so high that profitable businesses and larger projects can't do it or hire someone to do it for them. We should also continue work to make it less of a barrier (as MIRA has started to do, somewhat, in a two-steps-forward, one-step-back sort of way). That's also work I'm more interested in supporting via SPS.

          $0.00
            Reply
            [-]
             5 years ago  

            I'm obviously not arguing about access to ones own garage, I'm talking about access to the public road (which you were excluded from obtaining). Everything is excludable given some amount of effort, so a binary semantic don't make sense here.
            Anyway, this is just getting extremely pedantic about semantics, and we're not making progress, so I suggest we stop here, and agree to disagree.

            $0.00
              Reply
              [-]
               5 years ago  

              Oh, I guess I misunderstood. The idea was that parking a truck in front of my garage would control access to the road?

              The problem is that you would have to do this to everyone's garage, and it simply isn't feasible. I mentioned above some of the ways that controlling access to roads is starting to become more feasible but for the most part, in general, it still isn't.

              Agree to disagree, indeed.