Discuss mailing list

[krosos <gpunkt AT autistici.org>]

> Christopher:
> I can see both sides of the issue. I'm not sure there's any one good
> solution, but perhaps there's one that's "good enough".
> 
> My biggest thought is to maybe divide it up based on geographic area.
> This way everyone who would want to use OpenNIC (with perhaps
> exclusion to Antarctica...) is only affected by servers that are in
> the general "low latency" group for them. E.g. North America, South
> America, Europe, Africa, Asia, and Australia are the main divisions,
> though perhaps it could be divided up more if it calls for it. So
> (pulling examples out of nowhere) if North America and Europe are full
> of servers already, you can host more servers in those regions as
> you'd affect a smaller percentage of people than if you hosted servers
> in a less server-dense region (say, Africa).
I see an issue with this.
The regions where less servers are, are also the ones where servers cost
general much more than in mainland europe, scandinavia and north america.
This could be an issue for people who can't accept donations or are in
financial situations where it's not possible to just select a high
priced server there.
> 
> Apart from DDoSes, we don't seem to be hurting too much for server
> capacity. I think better situation of servers geographically and
> putting more resources into fewer servers to make them more reliable
> (redundant hardware/hosting) would be better than just getting a dozen
> or so cheap VPSes and tossing up servers on all of them.
> 
> Maybe if people want to have servers above the limit, they can pay in
> the funds they'd normally pay to an "OpenNIC T2 Pool" that'd let the
> group manage the servers, so they don't disappear if the person has to
> pull their hosting (whether cost or data center access issues). I'm
Is this possible when OpenNIC is no association or any legal body?
> picturing it as a list of servers. Each new one goes up in the
> geographic area most needing of a new server, rotating through the
> regions to keep them balanced. Before a new server can be brought up,
> funds for existing servers have to reach some minimum threshold (say,
> 6 months). This way we can smooth out irregularities in the funding
> for these servers.
> 
> I don't know if there's a good way to have "the group" manage the
> servers for that. Maybe it can pull from the main donation pool, with
> any leftovers after regular expenses going into the server pool.
> Obviously it'd put more work on the core folks of OpenNIC already
> maintaining the current infrastructure. Perhaps provide remote access
> so someone can donate to a server and become the administrator of it,
> but if they have to stop supporting it, they lose access and it's
> granted to someone else. It seems like our LDAP service could support
> that?
> 
> So yeah, vague ideas. Any comments?
That's just my limited, very distracted opinion at the moment, wouldn't
this idea require OpenNIC to become some legal body, like an association
- which doesn't necessarily involve any power structures like leaders or
whatever (see pirate party italy for such an example)?
> 
> 
> 
> On Fri, Oct 16, 2015 at 4:30 PM, Daniel Quintiliani <danq AT runbox.com> wrote:
>> There's only one problem - the DoS attacks that occasionally happen, 
>> OpenNIC would be less usable if there were fewer targets to take down.
>>
>> --
>>
>> -dan q
>>
>> danq.co
>> twitter.com/thebleakfire
>>
>> On Fri, 16 Oct 2015 13:55:33 -0600, Jeff Taylor <shdwdrgn AT sourpuss.net> 
>> wrote:
>>
>>> As you may (or may not) be aware, recently one of the T2 operators was
>>> forced to shut down most of their servers overnight. Unfortunately at
>>> the time, this person was running about 50% of the total list of public
>>> servers.  Messages were sent to the mailing list, the servers were
>>> removed from the listings, and some of the servers were able to brought
>>> back again soon after.
>>>
>>> We've had some debates on IRC already regarding whether there should be
>>> limitations placed on how many servers each individual is allowed to add
>>> to the public list (which affects things such as the nearest-servers
>>> info displayed on opennic's homepage).  There are pro and con points to
>>> this argument.  If we allow unlimited server entries, it greatly expands
>>> the reach of opennic with local servers in more countries.  However in a
>>> situation such as this, where a large number of servers are shut down at
>>> once, it hurts opennic's credibility and reliability, especially for
>>> those who like to set their DNS server entries and forget about them
>>> (this describes a large number of people who set up a home router or
>>> access point).
>>>
>>> Keeping this in mind, these are our options:
>>> 1) allow unlimited entries
>>> 2) limit the number of entries per person to a fixed number
>>> 3) limit the number of entries based on a formula, taking into account
>>> the current number of public servers, and/or the amount of time a user
>>> has successfully provided public servers.
>>>
>>> Number 3 seems to offer the best option, so long-time members can
>>> provide larger numbers of servers.  Even within that, there are
>>> sub-options to consider:
>>> 3a) Number is a percentage of total servers -- if there are 70 public
>>> servers and we user 10% as our base, then each user would be allowed to
>>> list 7 servers.
>>> 3b) Add the percentage to a base number -- we could allow everyone 5 +
>>> 10%, so as above this would currently give everyone a total of 12
>>> servers they could provide.
>>> 3c) Calculate a number from the length of time the user has been hosting
>>> public servers -- For a simple example, let's say 1 server per every
>>> month of hosting, so someone who has run servers for 10 months would be
>>> allowed to list up to 10 servers.
>>>
>>> Most likely we would want to create a combination of the above...
>>> something like a base of 2 servers, plus 5% of total servers for every 3
>>> months of hosting.  This would ensure a new user doesn't have too many
>>> entries to begin with, but that they become more trusted with long-term
>>> involvement with the project.
>>>
>>> Please discuss how this should be handled.  We need to decide how we
>>> want to handle this and implement a solid solution that is fair to
>>> everyone.  If you have ideas for a formula to use, please explain why
>>> you like it.  If there are other variables that should be considered,
>>> let me know and I'll see if it's something I can implement.
>>>
>>>
>>> --------
>>> You are a member of the OpenNIC Discuss list.
>>> You may unsubscribe by emailing 
>>> discuss-unsubscribe AT lists.opennicproject.org
>>
>>
>>
>>
>>
>> --------
>> You are a member of the OpenNIC Discuss list.
>> You may unsubscribe by emailing 
>> discuss-unsubscribe AT lists.opennicproject.org
>>
>>
>>
>>
>>
>> --------
>> You are a member of the OpenNIC Discuss list. 
>> You may unsubscribe by emailing 
>> discuss-unsubscribe AT lists.opennicproject.org