tilgovi

Here you are talking sense.

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.

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.

Nice! I didn't realize so much had been done on dataprotocols.org yet!

PouchDB is ready for some testing and play. Dale Harvey has put a lot of work into it recently: https://github.com/daleharvey/pouchdb

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 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.

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! 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.

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.

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.

I should add we have a low-volume list for outgoing announcements if you'd rather just hear those: announce+subscribe@list.hypothes.is

Thanks, zerostar07!

If you're interesting in helping out, watch https://github.com/hypothesis or subscribe to our dev list with dev+subscribe@list.hypothes.is

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.

My understanding is that attempts will be made to algorithmically promote diversity and to reward/punish social behaviors in such as way as to discourage discursive protectionism.

XMPP MUC is not fun, nor fun to scale. IRC has netsplits, but it does work reliably for tons of people all day every day.

Do it.

I think this is coroutines under the hood?

Not necessarily. A callback function with the standard signature under the hood is implied. If the author is controlling flow into and out of these execution contexts there is no reason an error passed to the implicit callback cannot cause an exception to be thrown into the original execution. Throwing exceptions into coroutines is a fairly normal pattern.

There's room for improvement. Most programmers shouldn't need to know how to write asynchronous code just as they shouldn't need to know how to write concurrent code. Consider mutexes vs Java's 'sychronized' vs transactional memory: there's a way forward, and it's to reduce complexity for the average programmer.

Remember that not everyone is as awesomely brilliant as you are.

node-fibers is one attempt to put coroutines into node. I like it because it uses libcoro, which is nice and tight and uses ucontext, and because it works as a module without forking the core of node. Once you've 'fiberized' the server modules to start each request in its own fiber and implemented a call-with-current-continuation on Function.prototype, we're pretty much at the same place you've arrived but without new keywords.

The thing to hope for is the death of the terminology and the proliferation, not consolidation, of technologies. Saying that all these diverse storage systems are all "NoSQL" and there will eventually be a "winner" is like saying that there will be one winner among Clojure, Scala, Java, JRuby, and Jython just because they all run on the JVM. Okay, so that's actually a bad comparison. In any case, what I mean to say is there's more than one thing moving under this blanket. Don't be fooled by the marketing.

The problem doesn't come with the inserts, it comes with the deletes, where CouchDB will keep some metadata and stubs around to support its replication use cases. In a pure logging setup this is perhaps less than ideal.

HBase might be a good solution, too, but I don't know a whole lot about it. CouchDB would work fine but you'd want to add some operational automation and a proxy to roll over between temporary databases since deleting old logs from a single database won't fully reduce its size and, as stated above, compaction isn't terribly fun or fast but you can avoid it by just flat out deleting old log databases.

I'd love to see a ctypes binding into Python of LevelDB, also. Anyone working on that?

Also, the version on master does what you suggest and makes no attempt to accommodate replication-based merging, thereby dealing implicitly with merging revision histories stemmed to a height of 2. "Real" CouchDB replication is what we aim for, though, and so this algorithm must be written.

I'm the one working on this right now and this is exactly what I'm doing. However, old document bodies are not the only way to store history. Documents have a revision history, possibly 'stemmed' to a maximum height, which is an array that traces a path from a certain depth back toward the root. All the leafs are conflicts. This is the algorithm davisp is talking about.

While I'm not going to leave the document bodies of superseded revisions accessible (by overwriting them in IndexedDB), I still need to store these history paths so that merging a new revision (either via interactive edit or replication) can properly generate a conflict when applicable.

As though the gender of the agent had any relevance...

Woohoo! I'll come by :)