What are the best limits for free-developer accounts?
11 views
Skip to first unread message
devrim
Jun 14, 2009, 9:58:37 PM6/14/09
to Kodingen
What we want?
- Developers can develop without even thinking about bumping into some
limits.
- Developers can earn money without paying for any infrastructure
- Developers can find work without being abused with inhumane bidding
procedures or underpaid by companies
What we don't want?
- Some malicious people to exploiting the system to porn, scam by
creating websites, subdomains or attacking other sites using Kodingen
- Draw a fine line between who should contribute to the costs of
Kodingen, who should not.
Currently for each account Kodingen sets these limits.
MySQL:
MAX_QUERIES_PER_HOUR 1000
MAX_UPDATES_PER_HOUR 1000
MAX_CONNECTIONS_PER_HOUR 1000
MAX_USER_CONNECTIONS 5
It is to avoid:
- users writing malicious scripts to capture other user's passwords.
- users slowing the system for others by (ab)using shared database
- free accounts should not have 24x7 live websites (which opens our
doors for porn and scam people on the net)
-
Malicious people :
- If we don't know the person which is the case for free-accounts, how
should we allow sub-domain creations?
- how do we disable porn.kodingen gambling.kodingen type accounts?
Two solutions
- user logs out, all the connections (sub-domains, ftp's) are dead,
and they are retrieved once they log in again.
- we ask credit card, but do not charge money (which gives us the id,
but a lot of people in developing countries don't have credit cards)
Storage and Traffic,
- We are thinking 100MB and 1GB traffic would be enough for people to
go out and do stuff without costing us a lot.
Then we should have number of FTP, number of Vhost limitations, SVN
Trac will follow, please write your opinions, let's first figure out
Mysql limits rest can continue for a long time with wider public.
Devrim
- Developers can develop without even thinking about bumping into some
limits.
- Developers can earn money without paying for any infrastructure
- Developers can find work without being abused with inhumane bidding
procedures or underpaid by companies
What we don't want?
- Some malicious people to exploiting the system to porn, scam by
creating websites, subdomains or attacking other sites using Kodingen
- Draw a fine line between who should contribute to the costs of
Kodingen, who should not.
Currently for each account Kodingen sets these limits.
MySQL:
MAX_QUERIES_PER_HOUR 1000
MAX_UPDATES_PER_HOUR 1000
MAX_CONNECTIONS_PER_HOUR 1000
MAX_USER_CONNECTIONS 5
It is to avoid:
- users writing malicious scripts to capture other user's passwords.
- users slowing the system for others by (ab)using shared database
- free accounts should not have 24x7 live websites (which opens our
doors for porn and scam people on the net)
-
Malicious people :
- If we don't know the person which is the case for free-accounts, how
should we allow sub-domain creations?
- how do we disable porn.kodingen gambling.kodingen type accounts?
Two solutions
- user logs out, all the connections (sub-domains, ftp's) are dead,
and they are retrieved once they log in again.
- we ask credit card, but do not charge money (which gives us the id,
but a lot of people in developing countries don't have credit cards)
Storage and Traffic,
- We are thinking 100MB and 1GB traffic would be enough for people to
go out and do stuff without costing us a lot.
Then we should have number of FTP, number of Vhost limitations, SVN
Trac will follow, please write your opinions, let's first figure out
Mysql limits rest can continue for a long time with wider public.
Devrim
devrim
Jun 14, 2009, 10:14:17 PM6/14/09
to Kodingen
* - Draw a fine line between who should contribute to the costs of
Kodingen, who should not.
should be on 'what we want' list.
Kodingen, who should not.
Duckness
Jun 15, 2009, 8:49:51 AM6/15/09
to Kodingen
This is a very difficult point. Because these things differ from
person to person. But this is my opinion:
- Developers can develop without even thinking about bumping into some
limits.
- Developers can earn money without paying for any infrastructure
- Developers can find work without being abused with inhumane bidding
procedures or underpaid by companies
What we don't want?
- Some malicious people to exploiting the system to porn, scam by
creating websites, subdomains or attacking other sites using Kodingen
- Draw a fine line between who should contribute to the costs of
Kodingen, who should not.
MySQL:
==> MAX_QUERIES_PER_HOUR 2000 (Drupal isn't able to install itselfs
and this is just an example off course but I'm almost sure there are
100s of other apps that won't be able to install with this limit since
Drupal isn't that big)
is to check them all yourself but that will take a lot of time so I'm
not sure yet about this feature.
- how do we disable porn.kodingen gambling.kodingen type accounts? ==>
Same as above but even more work since you gotta keep checking the
older subdomains too ...
Two solutions
- user logs out, all the connections (sub-domains, ftp's) are dead,
and they are retrieved once they log in again. ==> This might indeed
be a sollution but I thought Kodingen was meant to be a free host with
extra features to make devolopping applications easier. (Correct me if
I'm wrong, I was going to use it for development only anyway ^^)
people of at least 18 years old will be able to sign up for an account
and even then not everyone has one but it would indeed help to "scare
off" the abusers ... (Credit Cards are not very popular in Belgium
fe ...)
Storage and Traffic,
- We are thinking 100MB and 1GB traffic would be enough for people to
go out and do stuff without costing us a lot. ==> Depends on what
Kodingen is meant for. If it's meant for development only and not to
host final websites this should indeed be enough.
Greetz,
Maarten
person to person. But this is my opinion:
- Developers can develop without even thinking about bumping into some
limits.
- Developers can earn money without paying for any infrastructure
- Developers can find work without being abused with inhumane bidding
procedures or underpaid by companies
What we don't want?
- Some malicious people to exploiting the system to porn, scam by
creating websites, subdomains or attacking other sites using Kodingen
- Draw a fine line between who should contribute to the costs of
Kodingen, who should not.
==> MAX_QUERIES_PER_HOUR 2000 (Drupal isn't able to install itselfs
and this is just an example off course but I'm almost sure there are
100s of other apps that won't be able to install with this limit since
Drupal isn't that big)
MAX_UPDATES_PER_HOUR 1000
MAX_CONNECTIONS_PER_HOUR 1000
MAX_USER_CONNECTIONS 5
It is to avoid:
- users writing malicious scripts to capture other user's passwords.
- users slowing the system for others by (ab)using shared database
- free accounts should not have 24x7 live websites (which opens our
doors for porn and scam people on the net)
MAX_CONNECTIONS_PER_HOUR 1000
MAX_USER_CONNECTIONS 5
It is to avoid:
- users writing malicious scripts to capture other user's passwords.
- users slowing the system for others by (ab)using shared database
- free accounts should not have 24x7 live websites (which opens our
doors for porn and scam people on the net)
Malicious people :
- If we don't know the person which is the case for free-accounts, how
should we allow sub-domain creations? ==> The most efficient solution
- If we don't know the person which is the case for free-accounts, how
is to check them all yourself but that will take a lot of time so I'm
not sure yet about this feature.
- how do we disable porn.kodingen gambling.kodingen type accounts? ==>
Same as above but even more work since you gotta keep checking the
older subdomains too ...
Two solutions
- user logs out, all the connections (sub-domains, ftp's) are dead,
be a sollution but I thought Kodingen was meant to be a free host with
extra features to make devolopping applications easier. (Correct me if
I'm wrong, I was going to use it for development only anyway ^^)
- we ask credit card, but do not charge money (which gives us the id,
but a lot of people in developing countries don't have credit cards)
==> This is in my opinion really a bad idea cause that means that only
but a lot of people in developing countries don't have credit cards)
people of at least 18 years old will be able to sign up for an account
and even then not everyone has one but it would indeed help to "scare
off" the abusers ... (Credit Cards are not very popular in Belgium
fe ...)
Storage and Traffic,
- We are thinking 100MB and 1GB traffic would be enough for people to
Kodingen is meant for. If it's meant for development only and not to
host final websites this should indeed be enough.
Greetz,
Maarten
Glenn Heylen
Jun 15, 2009, 9:05:10 PM6/15/09
to Kodingen
The numbers suggested aren't really big. 100MB - spread over a number
of services - will be filled up quite easily. The traffic generated in
a bigger team will pass the 1GB limit without any trouble aswel. The
MySQL limitations will be a pain in the * for inexperienced query
builders. Lazy connections will make the account cross the 5
connection limit any time. You should consider that this platform is
mainly adressed to development phase. A phase where code and limits
aren't put to its best use.
I think at start (beta) it should all be a matter of throttling the
services. I shouldn't bother users that much with and limitations.
Though, you should ofcourse have some restrictions. After beta you'll
see what's the average number of queries / hour, etc. Just pick the
number where the least number of users are limited in their way of
working and where you guys have the best performance/lowest cost. You
won't be able to do good for everybody anyway. And after all: those
who are limited are obliged to work more efficient. Maybe they'll
consider caching their queries instead of sending the same one 300 /
hour.
I'd go with these numbers in beta:
MAX_QUERIES_PER_HOUR 10000
MAX_UPDATES_PER_HOUR 10000
MAX_CONNECTIONS_PER_HOUR 10000
MAX_USER_CONNECTIONS 25
of services - will be filled up quite easily. The traffic generated in
a bigger team will pass the 1GB limit without any trouble aswel. The
MySQL limitations will be a pain in the * for inexperienced query
builders. Lazy connections will make the account cross the 5
connection limit any time. You should consider that this platform is
mainly adressed to development phase. A phase where code and limits
aren't put to its best use.
I think at start (beta) it should all be a matter of throttling the
services. I shouldn't bother users that much with and limitations.
Though, you should ofcourse have some restrictions. After beta you'll
see what's the average number of queries / hour, etc. Just pick the
number where the least number of users are limited in their way of
working and where you guys have the best performance/lowest cost. You
won't be able to do good for everybody anyway. And after all: those
who are limited are obliged to work more efficient. Maybe they'll
consider caching their queries instead of sending the same one 300 /
hour.
I'd go with these numbers in beta:
MAX_QUERIES_PER_HOUR 10000
MAX_UPDATES_PER_HOUR 10000
MAX_CONNECTIONS_PER_HOUR 10000
MAX_USER_CONNECTIONS 25
Glenn Heylen
Jun 15, 2009, 9:29:22 PM6/15/09
to Kodingen
You can't avoid the abuse 100%. Yough, good risk management can limit
it dramaticly.
Sub-domains should be available to non-paying customers. I don't think
you have to limit functionality to increase the number of paying
customers. You have to hit a more fundamental value. E.g.: Not paying
= put everything he/she does in public domain. (Assembla has a good
approach to this though they are scandalously expensive)
Having that said: will there only be two kinds of accounts? Or will
there be free, cheap and expensive deviations?
Don't ask the 'free developer' for a credit card. The public you're
trying to reach will drasticly say no to Kodingen. Id checks are
always difficult. I think the mailaddress will do. You can purge the
user table which weren't active the last 6 months. Abusive names can
be avoided: the naming of domains and accounts can be validated
agains't an 'ugly words table'.
it dramaticly.
Sub-domains should be available to non-paying customers. I don't think
you have to limit functionality to increase the number of paying
customers. You have to hit a more fundamental value. E.g.: Not paying
= put everything he/she does in public domain. (Assembla has a good
approach to this though they are scandalously expensive)
Having that said: will there only be two kinds of accounts? Or will
there be free, cheap and expensive deviations?
Don't ask the 'free developer' for a credit card. The public you're
trying to reach will drasticly say no to Kodingen. Id checks are
always difficult. I think the mailaddress will do. You can purge the
user table which weren't active the last 6 months. Abusive names can
be avoided: the naming of domains and accounts can be validated
agains't an 'ugly words table'.
Glenn Heylen
Jun 15, 2009, 9:35:32 PM6/15/09
to Kodingen
Oh BTW: be sure to check Issue #38, which is quite related to this
subject.
subject.
devrim
Jun 16, 2009, 12:41:27 PM6/16/09
to Kodingen
Thanks for your ideas.
Glenn, I think your suggested limits are fine. I dislike credit card
check myself as well.
It just occurred to me, maybe we can build a trust network.
to unlock features, people seek 3 votes from our trusted members? 6
votes for further unlocking and 10 votes for becoming a trusted
member.
In turn, they will keep on eye on their trust network to gain even
further reputation (and access to more features), since trusted
members can damage their credibility by letting people do abusive
stuff.
This trust network can be utilized in case of necessary arbitration
between developers and companies on Kodingen too.
This requires a lot of thinking and implementation maybe, but with
this, Kodingen can really become a community... which we all want it
to be..
Thoughts?
Glenn, I think your suggested limits are fine. I dislike credit card
check myself as well.
It just occurred to me, maybe we can build a trust network.
to unlock features, people seek 3 votes from our trusted members? 6
votes for further unlocking and 10 votes for becoming a trusted
member.
In turn, they will keep on eye on their trust network to gain even
further reputation (and access to more features), since trusted
members can damage their credibility by letting people do abusive
stuff.
This trust network can be utilized in case of necessary arbitration
between developers and companies on Kodingen too.
This requires a lot of thinking and implementation maybe, but with
this, Kodingen can really become a community... which we all want it
to be..
Thoughts?
devrim
Jun 16, 2009, 12:45:14 PM6/16/09
to Kodingen
No credit cards, no payments no silly stuff will be necessary.
Community will reward good people and ban bad ones totally through
voting..
Community will reward good people and ban bad ones totally through
voting..
Maarten
Jun 16, 2009, 2:37:17 PM6/16/09
to Kodingen
I like the ideas about the voting, giving trust to other people. And
like you said it's probably gonna be quite some work but it's a nice
system. It's probably totally worth it.
Although I think people will start whining for trust votes and others
will just give them away. Or they'll just create a second account.
Maybe only trusted members should be able to trust other members?! Or
we can check on multi-accounts but that brings extra work. I don't
think we want this to become something like the Belgian law, back-
doors everywhere ^^
Maybe there's a way to avoid these problems. If I have any ideas I'll
post them here!
Greetz,
Maarten
like you said it's probably gonna be quite some work but it's a nice
system. It's probably totally worth it.
Although I think people will start whining for trust votes and others
will just give them away. Or they'll just create a second account.
Maybe only trusted members should be able to trust other members?! Or
we can check on multi-accounts but that brings extra work. I don't
think we want this to become something like the Belgian law, back-
doors everywhere ^^
Maybe there's a way to avoid these problems. If I have any ideas I'll
post them here!
Greetz,
Maarten
Nicolas Ruflin
Jun 16, 2009, 4:03:34 PM6/16/09
to kodi...@googlegroups.com
I also like the vote system.
devrim
Jun 16, 2009, 5:18:23 PM6/16/09
to Kodingen
Currently we think that, we will have kodingen.com and kodingen.org
Similar to wordpress.com and wordpress.org.
.com will keep on operating the same, free for developers being paid
by companies.
Companies will be able to claim unlimited hosting and traffic (5GB to
500TB) and unlimited users.
As a developer you may be invited to join to companies project teams,
and companies pay per user they add users to their teams.
Suppose a company would like to have 10 people they pay e.g. $1/user
$50 for 5TB so they pay $60 in the end of the month.
A developer can work in any number of companies, and while they work,
they will work on company's resources (filetree will have tabs to
switch between personal files and others) therefore, developer won't
have resource problems while working on other companies projects,
their environment will be paid by them. Which means we don't have to
give a lot of resources to free accounts because they won't need it
for personal use.
This is the model we came up with, so that developers can enjoy
developing and making money without being bothered by limitations of
the environment.
The essence of this discussion is, if you give developers more than
they need just because you like them, it will open the gates for bad
guys to come in and exploit the system, disturb the community and get
us in legal troubles which will result in us closing all the doors to
free features or worse, shutting down the site.
If we could ID our users and hold them responsible of their actions,
it'd solve all the hassle, but there is no easy way of doing this.
This is the problem.
One example is, if anyone ever distributes child porn via kodingen.com
sub-domain, or distributes copyrighted content, authorities will shut
down our site since we are allowing that to happen (think of
napster.com or youtube on copyright issues). Therefore we have to have
some measures preventing such disturbance.
On the other hand, we don't want to disturb good people who just want
to code and have fun. This is a very important point for us, we didn't
design Kodingen with the hopes of becoming millionaires, we just
wanted to give back to the community. And we want to stay this way,
eventually opening the project to open-source community and growing it
altogether.
I'm sure we can solve this challenge within the democracy we can
create through our community.
I will try to come up with a plan of voting and ranking if you guys
don't have any other ideas,
- companies can ID themselves (they have tax nr. and their payments go
through Kodingen)
- employees who work for them will give them/us their ID's or payment
information to get paid.
- companies can help us trust developers.
therefore,
- Kodingen can trust companies
- if you worked for a company and they trust you, they can rank you as
a trusted member
- in turn you can vote for 1 member to be trusted every month
(thinking out loud)
- developer should seek 3 votes to become trusted (thinking out loud)
some rules
- you can't sell the trust vote
- if 3 of your trustees are banned you are not trusted by the system
anymore
- if you engage in any illegality, you take down all your network with
yourself.
advantages for trusted members,
- ever-expanding usage rights, sub-domains, db's etc.
- taking part in arbitration between companies and developers maybe
being paid a small fee for the participation.
- listing as a credible member, increased good-will towards themselves
and favored responses from the community.
That's the outline of my thinking for now.
It will take some more thinking and work to keep our community clean
and safe, but we are committed. I'm sure we will succeed.
Cheers,
D
Similar to wordpress.com and wordpress.org.
.com will keep on operating the same, free for developers being paid
by companies.
Companies will be able to claim unlimited hosting and traffic (5GB to
500TB) and unlimited users.
As a developer you may be invited to join to companies project teams,
and companies pay per user they add users to their teams.
Suppose a company would like to have 10 people they pay e.g. $1/user
$50 for 5TB so they pay $60 in the end of the month.
A developer can work in any number of companies, and while they work,
they will work on company's resources (filetree will have tabs to
switch between personal files and others) therefore, developer won't
have resource problems while working on other companies projects,
their environment will be paid by them. Which means we don't have to
give a lot of resources to free accounts because they won't need it
for personal use.
This is the model we came up with, so that developers can enjoy
developing and making money without being bothered by limitations of
the environment.
The essence of this discussion is, if you give developers more than
they need just because you like them, it will open the gates for bad
guys to come in and exploit the system, disturb the community and get
us in legal troubles which will result in us closing all the doors to
free features or worse, shutting down the site.
If we could ID our users and hold them responsible of their actions,
it'd solve all the hassle, but there is no easy way of doing this.
This is the problem.
One example is, if anyone ever distributes child porn via kodingen.com
sub-domain, or distributes copyrighted content, authorities will shut
down our site since we are allowing that to happen (think of
napster.com or youtube on copyright issues). Therefore we have to have
some measures preventing such disturbance.
On the other hand, we don't want to disturb good people who just want
to code and have fun. This is a very important point for us, we didn't
design Kodingen with the hopes of becoming millionaires, we just
wanted to give back to the community. And we want to stay this way,
eventually opening the project to open-source community and growing it
altogether.
I'm sure we can solve this challenge within the democracy we can
create through our community.
I will try to come up with a plan of voting and ranking if you guys
don't have any other ideas,
- companies can ID themselves (they have tax nr. and their payments go
through Kodingen)
- employees who work for them will give them/us their ID's or payment
information to get paid.
- companies can help us trust developers.
therefore,
- Kodingen can trust companies
- if you worked for a company and they trust you, they can rank you as
a trusted member
- in turn you can vote for 1 member to be trusted every month
(thinking out loud)
- developer should seek 3 votes to become trusted (thinking out loud)
some rules
- you can't sell the trust vote
- if 3 of your trustees are banned you are not trusted by the system
anymore
- if you engage in any illegality, you take down all your network with
yourself.
advantages for trusted members,
- ever-expanding usage rights, sub-domains, db's etc.
- taking part in arbitration between companies and developers maybe
being paid a small fee for the participation.
- listing as a credible member, increased good-will towards themselves
and favored responses from the community.
That's the outline of my thinking for now.
It will take some more thinking and work to keep our community clean
and safe, but we are committed. I'm sure we will succeed.
Cheers,
D
devrim
Jun 16, 2009, 5:43:25 PM6/16/09
to Kodingen
by 'trust' I mean: in case of silly stuff we know who that person is.
in the same way;
'we can trust companies' doesn't mean they won't do nasty stuff,
however if they do, we know where they are and police can go after
them rather than shutting down our site. And if nasty people know that
they can be tracked down if they engage in nasty stuff, they won't
start it anyways. So we can keep them away from us.
So our 'trust' will be twofold; starts with being ready to be a person
in the system rather than a nickname+email (they can stay as a
nickname on display, but on records they are people), and our trust
grows with their utmost niceness towards community and being an
example to the rest of us.
It's a fine line that Maarten refers to, don't become a police but
don't let the police come in :)
I'm excited about this... This may be an example to the rest of the
internet, if we can do it right.
in the same way;
'we can trust companies' doesn't mean they won't do nasty stuff,
however if they do, we know where they are and police can go after
them rather than shutting down our site. And if nasty people know that
they can be tracked down if they engage in nasty stuff, they won't
start it anyways. So we can keep them away from us.
So our 'trust' will be twofold; starts with being ready to be a person
in the system rather than a nickname+email (they can stay as a
nickname on display, but on records they are people), and our trust
grows with their utmost niceness towards community and being an
example to the rest of us.
It's a fine line that Maarten refers to, don't become a police but
don't let the police come in :)
I'm excited about this... This may be an example to the rest of the
internet, if we can do it right.
devrim
Jun 16, 2009, 6:21:10 PM6/16/09
to Kodingen
Sorry guys for my consecutive emails, but I just thought of domain
names!
Most of us have at least one domain name... Domains are owned by real
people.
If user can set a CNAME on any domain that Kodingen can verify - we
have our trusted user!
Even the person doesn't own it, authorities will ask the domain owner
who is that person that they gave the password to, which is good
enough lead for the authorities, and an acceptable verification on our
part..
names!
Most of us have at least one domain name... Domains are owned by real
people.
If user can set a CNAME on any domain that Kodingen can verify - we
have our trusted user!
Even the person doesn't own it, authorities will ask the domain owner
who is that person that they gave the password to, which is good
enough lead for the authorities, and an acceptable verification on our
part..
Maarten
Jun 16, 2009, 7:11:53 PM6/16/09
to Kodingen
The ideas are not bad at all. About the domain thing. I'm not really a
fan. I own a domain myself but most domains are paid by credit cards
so that again requires a credit card.
And not everyone has one of their own (I used my parents credit card
fe). But it's not a bad idea because I guess you're aiming at
experienced developers?!
And most of those have a website of their own so it opens a new
thinking road ^^
But I like the trust system more. Just because it's innovative and it
might mean something to the rest of the internet. This might be nice
for the rest of the internet community. But off course it's still in
preposition state and this gotta be thought through very very well!
But I like the idea very much. I like the whole Kodingen thing, you
have nice ideas! But the big question is off course, how will this fit
in the so open internet of today? Although I personally think the
internet is a bit too open at this moment. There's too many abuse of
nice services.
A few months ago fe. I found out about an amazing free host. It was
really the best free host I ever used. And believe me I used a lot ^^.
But because 1 guy (or at least 1 user) hosted a website with child
porn on it and a few others where attacking the server they wanted to
stop and eventually their domain name was closed down by the
authorities. I was really sad about that and I didn't want any other
free host anymore. So I just bought myself some space on the net. I
learned my lesson there. You can't just do good to the world/internet
community without restrict people, without putting boundaries around
them. But with this voting system there might be a new way to
virtually remove those restrictions and boundaries.
But don't make it too hard for yourself. Sometimes it's better to take
the short road.
Greetz,
Maarten
> ...
>
> meer lezen »
fan. I own a domain myself but most domains are paid by credit cards
so that again requires a credit card.
And not everyone has one of their own (I used my parents credit card
fe). But it's not a bad idea because I guess you're aiming at
experienced developers?!
And most of those have a website of their own so it opens a new
thinking road ^^
But I like the trust system more. Just because it's innovative and it
might mean something to the rest of the internet. This might be nice
for the rest of the internet community. But off course it's still in
preposition state and this gotta be thought through very very well!
But I like the idea very much. I like the whole Kodingen thing, you
have nice ideas! But the big question is off course, how will this fit
in the so open internet of today? Although I personally think the
internet is a bit too open at this moment. There's too many abuse of
nice services.
A few months ago fe. I found out about an amazing free host. It was
really the best free host I ever used. And believe me I used a lot ^^.
But because 1 guy (or at least 1 user) hosted a website with child
porn on it and a few others where attacking the server they wanted to
stop and eventually their domain name was closed down by the
authorities. I was really sad about that and I didn't want any other
free host anymore. So I just bought myself some space on the net. I
learned my lesson there. You can't just do good to the world/internet
community without restrict people, without putting boundaries around
them. But with this voting system there might be a new way to
virtually remove those restrictions and boundaries.
But don't make it too hard for yourself. Sometimes it's better to take
the short road.
Greetz,
Maarten
>
> meer lezen »
devrim
Jun 16, 2009, 7:22:54 PM6/16/09
to Kodingen
See through the domain name you bought authorities can find you (in
this case through your family).. which is good because you will think
twice before doing anything evil.
Like you wouldn't put up an illegal site there, you will treat
Kodingen the same.
Thanks for the example that's exactly the problem with us. We can give
everything away, but they will be taken away if we are not careful.
> ...
>
> read more »
this case through your family).. which is good because you will think
twice before doing anything evil.
Like you wouldn't put up an illegal site there, you will treat
Kodingen the same.
Thanks for the example that's exactly the problem with us. We can give
everything away, but they will be taken away if we are not careful.
>
> read more »
Glenn Heylen
Jun 17, 2009, 2:12:29 AM6/17/09
to Kodingen
Woo.. fast expanding discussion!
So we are looking for a strict waterproof policy. I don't think
anything or a combination of limitations will mark the spot. The
healthy fear for legal trouble is ok, but it shouldn't grow too big.
Just look around on the internet. Eventually everything is associated
with everything. Any single tiny service can be abused. For the
creators it's all a matter of giving the ultimate responsibility to
the end-user. You can't sue Google either for deep linking into
confidential information. If you can show/prove that you have taken
measures to limit the illegal use, you'll be ok, I guess.
I'm thinking about stashing the CNAME suggestion in the same box as
the credit card one. You're requiring the user to have a paid service
in order to use a free service. It isn't an 100% tight id either, I
believe.
Asking the users to build up karma is cool. Though, where does it
start? Users get several points to start with? What will be available
to the user? Will that one restriction not push the user towards other
sas? It's harder to get karma if you are more limited in your actions.
Having friends (or fake friendships just to create a win-win
situation) will give you an advantage. For what reason should people
karma others? Work done in projects? What if they don't want to put
their project in the public domain? I also believe that a karma-vote
from you, Devrim, should be worth more than the karma from some random
non-paying user. Every karma should be relative to those who gave it.
Karmas should also be removable. One single good deed should not
reflect in life-time respect. There are a lot of questions to be
considered.
Maybe you should considering putting more activity streams on the
homepage. If someone did something what isn't allowed, there is a
bigger chance of being caught when that activity is visible to all
those who currently are at the homepage. Risk-full actions (creating
domains, linking own domain to sub) could be manually checked. I think
you'll be suprised how many people will work for free as moderator on
forums or such things. Also - refering to earlier idea - the impact of
someone - who was karma'd by you earlier - giving someone else karma
will be bigger. That way you can unconciously build your own network
of moderators.
There is still a lot that needs to be said, but I think you can
extrapolate from my ideas. I basicly want to say that you shouldn't be
that worried about all these ninja stories. Those who are sued aren't
mostly that innocent. Those who are put offline didn't respond to the
"Inquiry about illegal content copyrighted by WMG" - mail, I guess. If
you state that you can't be held responsible for the actions of users,
there isn't much that can be done if you aren't activily cooperating.
Try to create an atmosphere @ Kodingen that is very not-attractive to
bad users. Genuine users with genuine mailadresses, few not-active
projects/users, active group of moderators/admins, errata
> ...
>
> read more »
So we are looking for a strict waterproof policy. I don't think
anything or a combination of limitations will mark the spot. The
healthy fear for legal trouble is ok, but it shouldn't grow too big.
Just look around on the internet. Eventually everything is associated
with everything. Any single tiny service can be abused. For the
creators it's all a matter of giving the ultimate responsibility to
the end-user. You can't sue Google either for deep linking into
confidential information. If you can show/prove that you have taken
measures to limit the illegal use, you'll be ok, I guess.
I'm thinking about stashing the CNAME suggestion in the same box as
the credit card one. You're requiring the user to have a paid service
in order to use a free service. It isn't an 100% tight id either, I
believe.
Asking the users to build up karma is cool. Though, where does it
start? Users get several points to start with? What will be available
to the user? Will that one restriction not push the user towards other
sas? It's harder to get karma if you are more limited in your actions.
Having friends (or fake friendships just to create a win-win
situation) will give you an advantage. For what reason should people
karma others? Work done in projects? What if they don't want to put
their project in the public domain? I also believe that a karma-vote
from you, Devrim, should be worth more than the karma from some random
non-paying user. Every karma should be relative to those who gave it.
Karmas should also be removable. One single good deed should not
reflect in life-time respect. There are a lot of questions to be
considered.
Maybe you should considering putting more activity streams on the
homepage. If someone did something what isn't allowed, there is a
bigger chance of being caught when that activity is visible to all
those who currently are at the homepage. Risk-full actions (creating
domains, linking own domain to sub) could be manually checked. I think
you'll be suprised how many people will work for free as moderator on
forums or such things. Also - refering to earlier idea - the impact of
someone - who was karma'd by you earlier - giving someone else karma
will be bigger. That way you can unconciously build your own network
of moderators.
There is still a lot that needs to be said, but I think you can
extrapolate from my ideas. I basicly want to say that you shouldn't be
that worried about all these ninja stories. Those who are sued aren't
mostly that innocent. Those who are put offline didn't respond to the
"Inquiry about illegal content copyrighted by WMG" - mail, I guess. If
you state that you can't be held responsible for the actions of users,
there isn't much that can be done if you aren't activily cooperating.
Try to create an atmosphere @ Kodingen that is very not-attractive to
bad users. Genuine users with genuine mailadresses, few not-active
projects/users, active group of moderators/admins, errata
>
> read more »
devrim
Jun 17, 2009, 8:56:43 AM6/17/09
to Kodingen
Maybe combination of everything that has been said here...
- New user will request web presence from another trusted user (or
from a user group).
- He will connect his account to that user's acc. to create
webrooots,
- This user's/group's account will act like a company account, and it
will provide controlled access to extra features to new comers.
- So group can always check activity, newcomer can create webroots
Or, for a person who thinks this is too much, other options;
- if you can put a CNAME up, we can ID you
- if you have a credit card ID yourself right away
- if you have worked for a company and provided your ID's
Glenn, our aim is not just giving people points. It would be cool to
have some people with those points, but they don't mean anything in
case of illegality.
Illegality is ,on the other hand, a genuine concern and you can't just
get away with it by making people click on I agree in the case of
child porn or gambling. Even if your moderators work for free (i
believe they will) and 50 of them work on the system, 1 site that is
up, is not cleaned up, forgotten will get us in trouble.
So trust starts from 'proof, lead, clue that leads to the physical
person at a physical address'. Karma points are good for community but
not for police.
It's just that, measures taken for bad people will create distaste on
good people's thinking... I know that. Yet I know (from experience)
once you are identified as a potential exploit target, no amount of
moderators can stop those nasty people.
> ...
>
> read more »
- New user will request web presence from another trusted user (or
from a user group).
- He will connect his account to that user's acc. to create
webrooots,
- This user's/group's account will act like a company account, and it
will provide controlled access to extra features to new comers.
- So group can always check activity, newcomer can create webroots
Or, for a person who thinks this is too much, other options;
- if you can put a CNAME up, we can ID you
- if you have a credit card ID yourself right away
- if you have worked for a company and provided your ID's
Glenn, our aim is not just giving people points. It would be cool to
have some people with those points, but they don't mean anything in
case of illegality.
Illegality is ,on the other hand, a genuine concern and you can't just
get away with it by making people click on I agree in the case of
child porn or gambling. Even if your moderators work for free (i
believe they will) and 50 of them work on the system, 1 site that is
up, is not cleaned up, forgotten will get us in trouble.
So trust starts from 'proof, lead, clue that leads to the physical
person at a physical address'. Karma points are good for community but
not for police.
It's just that, measures taken for bad people will create distaste on
good people's thinking... I know that. Yet I know (from experience)
once you are identified as a potential exploit target, no amount of
moderators can stop those nasty people.
>
> read more »
Sinan
Jun 17, 2009, 4:41:46 PM6/17/09
to Kodingen
Hello,
I've included myself little bit late on this discussion, it took
pretty long to read all the stuff above.
I'll keep it short, I don't believe in democracy, a top control
mechanism like "skynet" in Terminator series would solve the
problem. :)
My suggestions to create a skynet are:
in general:
- No credit card, No domain info
I don't believe that they're effective solutions, ok we understand
that we deal with a real person but from the other side it irritates
the majority and it would keep people away. Like itunes kept me away
for almost a year till i enter my credit card details when i really
needed it.
- extending site-wide activity is a great idea btw.
"Sinan created blog.sinan.kodingen.com 3 days ago." such
notifications will make user feel "Be careful you're being watched by
the community."
for porn/illegal content:
- A smart server side crawler which checks user files regularly, if
the user hosts many images or videos it can notify us by an email and
the files of this user can be checked. (of course we have to inform
user when he registers)
- to show more respect to user's privacy an improve on this approach
might be that some random selected files can be attached to the
notification email without user info, if the content is suspicious
moderator can ask system whom the files belong or report to kodingen
admin.
for vandals (who wants to damage kodingen for no reason):
- cpu usage and bandwidth check per user, i don't know if it is
possible to make a cpu check per user but would be very nice to limit
the usage or freeze user.
for now it's what i can think of.
wil continue later.
Sinan.
I've included myself little bit late on this discussion, it took
pretty long to read all the stuff above.
I'll keep it short, I don't believe in democracy, a top control
mechanism like "skynet" in Terminator series would solve the
problem. :)
My suggestions to create a skynet are:
in general:
- No credit card, No domain info
I don't believe that they're effective solutions, ok we understand
that we deal with a real person but from the other side it irritates
the majority and it would keep people away. Like itunes kept me away
for almost a year till i enter my credit card details when i really
needed it.
- extending site-wide activity is a great idea btw.
"Sinan created blog.sinan.kodingen.com 3 days ago." such
notifications will make user feel "Be careful you're being watched by
the community."
for porn/illegal content:
- A smart server side crawler which checks user files regularly, if
the user hosts many images or videos it can notify us by an email and
the files of this user can be checked. (of course we have to inform
user when he registers)
- to show more respect to user's privacy an improve on this approach
might be that some random selected files can be attached to the
notification email without user info, if the content is suspicious
moderator can ask system whom the files belong or report to kodingen
admin.
for vandals (who wants to damage kodingen for no reason):
- cpu usage and bandwidth check per user, i don't know if it is
possible to make a cpu check per user but would be very nice to limit
the usage or freeze user.
for now it's what i can think of.
wil continue later.
Sinan.
Ruflin
Jun 17, 2009, 4:55:51 PM6/17/09
to kodi...@googlegroups.com
One other thing is, I think in general subdomains should be only
accessible by the owner (developer) and invited users (with this you
also gain more users)
The reason is, that I'm developing a project based on this url. And
during developing I have debugging outputs an all this stuff activated
that shouldn't be shown to users. And I really don't want other users
and guest to see all this stuff. Sure, I can use a .htaccess file to
prevent the access. But from my point of view, it should be closed by
default. And if it loads a subdomain, it checks if the user has access
to it.
accessible by the owner (developer) and invited users (with this you
also gain more users)
The reason is, that I'm developing a project based on this url. And
during developing I have debugging outputs an all this stuff activated
that shouldn't be shown to users. And I really don't want other users
and guest to see all this stuff. Sure, I can use a .htaccess file to
prevent the access. But from my point of view, it should be closed by
default. And if it loads a subdomain, it checks if the user has access
to it.
Sinan
Jun 17, 2009, 6:58:37 PM6/17/09
to Kodingen
Ow, this topic is going to different areas...
Anyways, i thought of a quick and user friendly solution for what
Ruflin offered here. It'd be enough if we just show "make public" and
"make private" options on modal box when you create a new webroot. If
"private" selected we can put an auto generated .htaccess file under
the folder. But i am against to make it private by default.
Anyways, i thought of a quick and user friendly solution for what
Ruflin offered here. It'd be enough if we just show "make public" and
"make private" options on modal box when you create a new webroot. If
"private" selected we can put an auto generated .htaccess file under
the folder. But i am against to make it private by default.
devrim
Jun 18, 2009, 12:59:45 PM6/18/09
to Kodingen
I like automated crawling on user's files by the system (skynet),
ensuring privacy and system sanity. This looks like an option that can
be implemented much sooner than any other thing that we have
suggested.
On the other hand, democracy is a good thing, voting other members
will have many other uses throughout the system and make our community
trust each other quicker since we also want to help each other on each
other's projects (volunteering, it's not always about money). On
volunteering, you will be wiling to open up your code to another
person if you have basic ideas about that person (he is trusted and
took part in many other projects succesfully)
ensuring privacy and system sanity. This looks like an option that can
be implemented much sooner than any other thing that we have
suggested.
On the other hand, democracy is a good thing, voting other members
will have many other uses throughout the system and make our community
trust each other quicker since we also want to help each other on each
other's projects (volunteering, it's not always about money). On
volunteering, you will be wiling to open up your code to another
person if you have basic ideas about that person (he is trusted and
took part in many other projects succesfully)
Reply all
Reply to author
Forward
0 new messages