hawkett said: When you say credit free currency, do you mean credit free society? How do you plan to make it credit free - through legislation? What's to stop me lending some currency I have in your system to someone - or making a purchase on their behalf in exchange for a purchase by them of something more valuable at a later date? That scenario is essentially an interest bearing loan. The system and those that use it exist in a symbiosis - you can't change one without addressing the other - it's hard to see how you will create a credit free society without addressing the psychology of the people within that economy - people need to *want* to avoid credit, and when you haven't got much, and others seem to have so much, credit is an insidiously attractive proposition - it's easy to market and sell. You'll probably need to address the gulf between rich and poor, and marketing of impossible, unaffordable goals to remove credit from society - perhaps you feel that economic collapse will do that. Does your plan deal effectively with the reality of the flawed, selfish human being? I guess I'm asking about your second point - is it based on a global societal enlightenment occurring due to the economic collapse?
I am an economist not a dreamer: a credit is a contract. The willingness to sign it is based on the belief that it will be enforced. If there is no enforcement of such a contract I bet you $1 that no body will do enter that kind of contract. Moreover I don't have to explain how data mining can help spot a transaction that is not a regular economic transaction but a credit. On 25 May 2010 00:25, Keren Or Shalom <v07768198...@gmail.com> wrote: > Please make your remarks shorts and focussed: > > I will answer to all I have received but break them down to something we > can digest: > > hawkett said > > > A small issue if the economy goes down the drain on the scale you are > talking about is that an internet where everyone has the capability to > connect to a cloud system is going to be difficult to maintain. It's > not going to be easy for google to make money, for individuals to pay > their internet bills, for internet companies to continue to deliver > access - indeed you may find it difficult for yourself to make money > or pay for the developers you are proposing to hire. What value will > money have? How will google pay its employees to continue to deliver > app engine - ad revenues are going to plummet. I think if your system > is anticipating the total collapse of the economy, then you may find > it difficult to deliver your system to what remains. > > > It all depends on how much my system can create demand: you are reacting > just as if the previous system didn't existed and we stayed in a vacuum. My > system is designed to feel the vacuum. > > > On 24 May 2010 16:08, hawkett <hawk...@gmail.com> wrote: > >> @gops this style of system is the holy grail of distributed systems, >> however the model you have suggested perhaps suffers from lack of >> redundancy. If only you have your data (or some of your data), and >> only you have access to it, then failure at that point represents >> total loss. The solution is a network of trust and redundant copies of >> your data and multiple people with the capacity to access it. The >> biggest problem we have with this solution is bandwidth and network >> latency. Keeping copies of data in different locations is expensive >> on both those fronts - especially if you want decent consistency, and >> especially between your computer and my computer. Another problem is >> that if publicly available data on your node is popular - then you >> need massive resources to be able to meet that demand - as you noted, >> a problem is the need for you to maintain your node. Perhaps the data >> distribution you mention is intended to solve these problems. >> >> For many classes of application, the cloud is actually the best we can >> do at the moment with the state of technology. Companies like google, >> amazon etc. *do* distribute data like this. However to solve the >> bandwidth and latency issues that come with the need for good >> consistency, they need to manage the clusters. I expect that one of >> the major reasons google is pushing hard for better bandwidth and >> lower latency for everyone is to expand the possibilities for this >> type of architecture. It won't be too long before our web browser is >> also a web server. I don't doubt that this forms a large part of the >> vision for Chrome OS. Another huge help will be getting people >> comfortable with eventual consistency. >> >> One of the key future applications of the social web is the >> application of networks of trust that allow us to distribute data to >> trusted nodes - the best people to store redundant copies of your data >> are the people you trust personally. It sounds like the guys on that >> link you posted are really pushing the boundaries of this stuff. >> >> Resistance is futile :) >> >> >> On May 24, 12:52 pm, gops <patelgo...@gmail.com> wrote: >> > @hawkett last line was the perfect answer to @keren. >> > >> > instead of making a central system on cloud , designing a software >> > that is very highly distributed using highest encryption standard is a >> > way to go. >> > >> > on some level , people athttp://www.joindiaspora.com/are doing that >> > thing at social networking level. ( personally i dont think doing this >> > on top of other http or https protocol is good idea. even >> > though creating/defining protocol is hard work , it should be done >> > directly on top of tcp/ip level. ) >> > >> > that way, i own my own server at my own location with my own data >> > fully encrypted and accessible only to me. then i delegate >> > data through defined protocol to other person or system ( be it a >> > company , a bank , a friend , a community etc.. ) with different level >> > of data and security access. same way, other system, >> > users and bank etc will delegate their data to my server to similar >> > encryption channels. >> > >> > distributing data this way will remove "scalability need" altogether. >> > and application complexity will reduce dramatically as they do not >> > have to take care of 1000's of connection or users. but it will arise >> > problem for myself to maintain my server , will force to learn a new >> > software etc and learn the system, may be your own private virtual >> > server is a new commodity of the future. >> > >> > my two cents. :D >> > >> > On May 24, 4:08 pm, hawkett <hawk...@gmail.com> wrote: >> > >> > >> > >> > > A small issue if the economy goes down the drain on the scale you are >> > > talking about is that an internet where everyone has the capability to >> > > connect to a cloud system is going to be difficult to maintain. It's >> > > not going to be easy for google to make money, for individuals to pay >> > > their internet bills, for internet companies to continue to deliver >> > > access - indeed you may find it difficult for yourself to make money >> > > or pay for the developers you are proposing to hire. What value will >> > > money have? How will google pay its employees to continue to deliver >> > > app engine - ad revenues are going to plummet. I think if your system >> > > is anticipating the total collapse of the economy, then you may find >> > > it difficult to deliver your system to what remains. >> > >> > > When you say credit free currency, do you mean credit free society? >> > > How do you plan to make it credit free - through legislation? What's >> > > to stop me lending some currency I have in your system to someone - or >> > > making a purchase on their behalf in exchange for a purchase by them >> > > of something more valuable at a later date? That scenario is >> > > essentially an interest bearing loan. The system and those that use >> > > it exist in a symbiosis - you can't change one without addressing the >> > > other - it's hard to see how you will create a credit free society >> > > without addressing the psychology of the people within that economy - >> > > people need to *want* to avoid credit, and when you haven't got much, >> > > and others seem to have so much, credit is an insidiously attractive >> > > proposition - it's easy to market and sell. You'll probably need to >> > > address the gulf between rich and poor, and marketing of impossible, >> > > unaffordable goals to remove credit from society - perhaps you feel >> > > that economic collapse will do that. Does your plan deal effectively >> > > with the reality of the flawed, selfish human being? I guess I'm >> > > asking about your second point - is it based on a global societal >> > > enlightenment occurring due to the economic collapse? >> > >> > > If you don't have much money to back this venture then a few points >> > > stand out >> > >> > > 1. The cloud is *much* cheaper than any custom hardware installation >> > > you can come up with. Security isn't just data security - you need to >> > > manage backups, uptime, support, maintenance, facilities, redundancy, >> > > disaster recovery - long list of stuff that will cost you buckets >> > > before you even get started. >> > >> > > 2. You need to do some risk assessment. There are always risks, and >> > > many of them - there is no perfectly secure system, and it is >> > > important not to try and sell such a thing. It is just a matter of how >> > > you rate each risk, and important that the stakeholders understand the >> > > risk and agree to it - the last thing you want to have is a >> > > conversation where someone says 'You told me it was secure!!!'. It >> > > can't be secure unless it is truly inaccessible to everything and >> > > everyone, and you can't build a system around that :). Risk assessment >> > > is generally subjective - what is the chance of someone obtaining a >> > > password they shouldn't? What is the chance of the cloud vendor >> > > exposing data? What is the chance that your code contains bugs? What >> > > is the chance of the cloud vendor losing your data entirely - >> http://gigaom.com/2009/10/10/when-cloud-fails-t-mobile-microsoft-lose... >> > > The list goes on. If you build a system where there is perceived value >> > > in subverting it, then it will probably be subverted. It is much >> > > better to cope with it than try to prevent it (you can't prevent it). >> > > What you need to prevent against is the possibility that any >> > > particular problem or combination of problems results in total >> > > failure. >> > >> > > Some key questions you need to ask - >> > >> > > 'What is the worst that can possibly happen?' >> > > 'How likely is it?' >> > > 'What can I do to reduce the worst that can possibly happen, and the >> > > chance that it will happen - i.e. how do I mitigate my risk?' >> > > 'Can I afford to implement mitigation strategy X, Y or Z?' >> > > 'Am I prepared to accept the consequences of the risk being realised?' >> > > Usually it is easier to answer yes to this question when the rewards >> > > (not necessarily financial) are higher. >> > >> > > You need to deliver a system that allows you to answer yes to the last >> > > question, for every risk you identify. Sometimes you cannot reach the >> > > point where the answer is 'yes' - the risk is not worth the reward. >> > >> > > <slight political rant (IMO)> >> > > A good example is the recent financial crisis. The banking sector took >> > > risks, understanding that the worst possible outcome (for them) was >> > > not actually as bad as is being portrayed - they felt that they would >> > > still not fail because they commanded enough political power to rely >> > > on federal funds. So what seemed incredibly risky behaviour by the >> > > banks, was, in fact, not all that risky - because they had shored up >> > > their political power to mitigate their risk. Consequently, the worst >> > > that could possibly happen with all the risks the banks took was that >> > > they would be fine. And largely, they are fine. Good risk management >> > > they would say - it wasn't all that risky. Not for them. Incredibly >> > > risky for the taxpayer, but that risk wasn't their concern - at least >> > > not from their perspective. You can be sure that it was a possibility >> > > they were aware of. The nation(s), however, totally lost a handle on >> > > their risk management - the banks should never have been allowed to >> > > reach a position where they could mitigate their risk with federal >> > > funds - essentially the risk was transferred to the tax payer. If they >> > > were unable to do that, then they wouldn't have taken the risks in the >> > > first place, because they could not have answered 'yes' to the last >> > > question. It is difficult to see how the nation(s) could have avoided >> > > this problem though - the stakeholders (the citizens) have very >> > > limited means by which to limit the subversion of power from within >> > > their political process - most of these powerful people within >> > > government are not elected. >> > > </slight political rant (IMO)> >> > >> > > You might also consider an approach to security like Google's - they >> > > offer a platform so compelling that many customers will use the system >> > > despite google making no promises on security or reliability - 'use at >> > > your own risk'. Is your product so compelling that you can mitigate >> > > some of your risk by transferring it to your customers? Google also >> > > benefits here from significant goodwill and reputation, but that takes >> > > time and evidence - we have seen in their reaction to the Chinese >> > > hacking scandal that they take the compromise of customer data very >> > > seriously. >> > >> > > My gut feel is that the security you want, you can't afford - so use >> > > the cloud, encrypt the personal data you need to, and mitigate the >> > > remaining risk by transferring it to your users. Just make them aware >> > > of the risk they are taking - you might find they'll accept that risk >> > > and use your system anyway. Where google basically says 'Trust us, >> > > we're Google', you need to say 'Trust me, it's on Google'. Most of the >> > > customers that would go for the first statement will go for the >> > > second. >> > >> > > You say it would not be responsible to trust google - but this is what >> > > you are asking of your customers - to trust you with the security of >> > > their information. Trust is a huge factor in risk assessment and >> > > security. Many banks trust third party organisations with customer >> > > information, or to write software that secures customer information. >> > > You're going to have to trust someone. >> > >> > > I think history and common sense tells us that our economy will >> > > probably go down the chute at some point - our system is pretty >> > > tightly strung, and doesn't cope very well with fairly minor >> > > disturbances. It's utterly dependent upon confidence, and totally >> > > global. Natural systems manage risk through redundancy and diversity - >> > > failure doesn't bring the whole thing down. I doubt our brilliant idea >> > > of having one global economy is going to have nature going - 'Hey, why >> > > didn't I think of that?' - more like - 'Tried that, didn't work - you >> > > should have asked. In the meantime, here's a small icelandic volcano >> > > to deal with - get the idea?'. We are selfish idiots ruled by selfish >> > > idiots, urging each other to become more so. Probably not the best >> > > architecture we could come up with. Our society could learn something >> > > from the way we build distributed software. >> > >> > > On May 24, 7:06 am, Keren Or Shalom >> > >> > ... >> > >> > read more ยป >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To post to this group, send email to google-appeng...@googlegroups.com. >> To unsubscribe from this group, send email to >> google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> >> > > > -- > V07768198309 > -- V07768198309 -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
