Except you're the one who brought up $200k as a number to begin with. And those people who sold themselves into debt slavery, by going to an extremely good school, may actually still hold jobs that will allow them to repay their loans eventually. Ignoring your arbitrary choice of debt number, we're looking at many people in debt and many of them without any college degree whatsoever.
And talking about parents isn't helpful. Parents are the ones watching the State of the Union address where the President talks about higher education and competing with China and then go out in the town and talk to the other parents about where their children are going to college and what their children are doing with their degrees. Thinking that only 18-year-olds can be fooled into saddling themselves with excessive debt is nonsense.
>Except you're the one who brought up $200k as a number to begin with.
Yes.
>And those people who sold themselves into debt slavery, by going to an extremely good school, may actually still hold jobs that will allow them to repay their loans eventually.
Well then, there's no problem, is there?
>Thinking that only 18-year-olds can be fooled into saddling themselves with excessive debt is nonsense.
At some point people have to think for themselves.
Hahahaha. I've totally posted my response to a recruiter on FB before, because I had to vent about it. He nails every important point, including that we should have some sympathy because they are incentivized, at least in the short term, to shotgun blast. OTOH, it sucks to complain at all about getting recruited when so many are unemployed or underemployed.
I'll see what I can do about getting a good publication of the replication protocol. People have been asking about it for a long time. I've only come to fully grok it late last year when I tried to write PouchDB and I talked through it with Dale when he picked up my slack. We can probably get that together.
A great first example that I'd love to see is using PouchDB to implement Backbone.Sync for a Backbone app.
I think Jon was just trying to provide some information on the spectrum of possible identity solutions one can choose from. At Hypothes.is, it's extremely unlikely we would try to do anything like this. However, it does represent a form of "verified pseudonymous" identity, in which your uniqueness as an entity is verified by a central authority, but that identity is never exposed. See my comment below for more information about what we might actually implement.
This reply still seems to indicate a fundamental misunderstanding of multifaceted identity. The fact that i am one physical person should be irrelevant to a reputation service. If I have one identity that I use to post jokes on reddit and another identity that I use to post serious content, those identities should have different reputations. What I do with one should not affect the other. My uniqueness should not have to be verified, the only thing that should matter towards my reputation is what the persona I am currently acting as has done before.
Yes. I totally agree. I would certainly love to support multiple distinct personas. There is an open question of how to do that while mitigating the damage potential. There are also cases where multiple personas might usefully be linked. For example, when commenting on programming issues you might want to link your persona to your stackoverflow identity or your HN account. Honestly, the biggest mistake I could make would be to assume I know what the community wants before we have a community. I think it's probably wise to err on the side of less friction and more prismatic identity and deal with restricting multiple signups if/when we need to. For now I plan to enforce uniqueness for outside identities (only one pseudonym per Twitter account) but also allow a basic reCAPTCHA username/password signup. If someone wants to contribute code to manage multiple personas within one account that would be fabulous, but annotation functionality feels more priority for me. If you think there's still a fundamental misunderstanding please continue, but I totally agree with your comment and don't think there's anything about it that's incompatible with my current vision.
Thanks for the clarification. But the concern remains that a single "central authority", namely hypothes.is, gets to maintain a huge database that links online pseudonyms to verified real-world identities. That's going to make hypothes.is one hell of a target, not only for identity thieves but also for government authorities of all stripes. Meanwhile you'll need to convince people that they should trust you with that information.
Sure, any large online identity provider that possesses enough data to link online identities to real-world identities (such as Facebook) will face the same problem. If this takes off, Chinese hackers will be crawling under your mattress and your PO Box will be overflowing with subpoenas and national security letters before you can say eff-bee-eye. But ideally I'd like to see this problem fixed in some creative way, not merely repeated and exacerbated in a centralized form.
Honestly, I have no idea how one might achieve both verification and pseudonymity without cutting corners somewhere else. But I do have some hope for you guys because it seems that EFF is involved. Those people really know how to play with pseudonyms.
Thanks! Wherever possible I'd like to ditch the personal information after signup and just keep a hash or something that we can use to prevent multiple accounts using the same Twitter, OpenID, etc, linking only these opaque tokens to user IDs in our database. I'm trying to put together our user tables and login system in the next day or so and welcome any comments or concerns you have with the implementation. Feel free to jump into our dev list or #hypothes.is on Freenode.
That raises an interesting question. How are you going to hash a person's Twitter username or OpenID in such a way that (1) you can quickly determine if the same person tries to sign up more than once using the same credentials, and (2) the original credentials are effectively discarded?
If you just store something like sha1(openid), it will be easy to check for duplicates, but any staff, intruder, or three-letter agency that wants to connect hypothes.is accounts with OpenID's can also easily launch a dictionary attack. On the other hand, if you store something like bcrypt(salt | openid), it will be a lot of hassle to check for duplicates, and your database is still susceptible to a known-plaintext attack. In neither case have you actually irrecoverably discarded the personal information. And thus we get back to the problem of South Korean web sites requesting National ID numbers from every member. They only claim to use it to prevent multiple signups, but then they wonder why every Chinese hacker has easy access to millions of South Korean National ID numbers.
Meanwhile, nothing prevents a determined spammer from creating multiple Google (for OpenID) or Twitter accounts. So if I had a suggestion, it would be that you should stop wasting time trying to enforce one account per person, and instead give people an incentive to minimize the number of accounts they create. Make it dead easy for people to associate different accounts on different services with any of their personas, and make it dead easy for people to organize and manage them, so that most people don't even feel the need to create additional accounts.
Feel like using your joke personality on Reddit today? Just select that persona in a dropdown menu in the browser add-on bar. Wanna switch to your serious account for just one comment? Another click in the menu and you're automatically logged in as the other user. (Reddit Enhancement Suite can already do something like this, which means there's a demand for this feature.) Different example: I sometimes want to log into Gmail with one Google account while browsing YouTube with another Google account. Right now, this means messing with incognito windows. If each tab were pinned to a different persona, I could do this just as easily as flipping Chris Poole's prism in my palm.
I started thinking about the dictionary attacks, too, and ultimately you're right. Not worth enforcing and easy dropdown changing is eventually what we want. Thanks for your thoughts.
We're not trying to compete for attention in the social web. Part of that is reflected in our involvement with the W3C Open Annotation Working Group (http://www.w3.org/community/openannotation/). While Hypothes.is may be one place to publish, the goal is to provide better linking and referencing tools to facilitate aggregators and plugins that can bring the conversation back to the source material. In other words, to bring this conversation on HN into the RWW frame and vice versa and to allow better quoting and transclusion between these content silos.
Quite the opposite, actually. I will be seriously considering the privacy implications of everything we do. One of our core principles is a commitment to pseudonymous accounts. To the extent we allow multiple identities to be linked to one account, it will be in your control to do so (or not) as suits your multi-faceted persona, tin foil hat paranoias, or legitimate privacy concerns. While we understand there is a social cost to cheap pseudonyms (see Friedman, Resnick (2001) http://www.si.umich.edu/~presnick/papers/identifiers/081199....), we believe we can develop a reputation system and a user community that resists gaming attempts without significant barriers to entry or privacy-invading personal information mining.
The goal of Hypothes.is is, on the contrary, to be a forum where you can voice your opposition to policies you find to be ushering in a police state and have the community weigh in on an informed discussion.
That's only true under the assumption that popularity is the only factor in visibility. On hacker news that's not even true entirely because there's a temporal factor: new postings remain visible for at least a short time. However, there may exist other possible ways to artificially increase visibility in order to promote diversity. Some of these methods are the research subject of Paul Resnick at the University of Michigan who is listed as an advisor.
