tottenhm

> The isolation of academia from reality is so large that you almost have to say it is deliberate.

Yes... but for context, we can compare an academy with a factory, a military, a primary school, a hospital, a ride-share, or a church. If a person spends the majority of his time on writing papers, shaping steel, marching in formation, tagging on a playground, tending to sick people, driving strangers around the city, or praising god... well, all that focused labor is going to warp his world view a bit. And that is quite deliberate. Institutions are defined by how they isolate their members, direct their members' focus, and acquire comparative-advantage.

Of course, institutions in our time are not absolute. If we turn our attention away from categorical institutions... and instead look at individuals... then the situation gets much more interesting and less dark (but still imperfect)...

An interesting point. There was a similar issue with SMS (federating with big telcos), and Whatsapp (among others) did a nice job of routing around that (by piggybacking on SMS). It's interesting to think about how a genuinely open player might route around that.

For example, suppose you want to send an IM to your friend. You believe in XMPP or some other open/federated protocol, but you don't know which friends use the protocol. Piggyback off email. Note that identities are backed by email. Also, if any identity-providers refuse to join the federation, then route through a trusted fallback service (Trent.com). Pseudocode:

function send_im(toEmailAddr, messageText) { // See if the user's domain already supports OpenChatProto. if (nslookup(toEmailAddr.hostname, 'SRV', 'OpenChatProto')) return OpenChatProto.deliver(toEmailAdrr, messageText);

  // If user's domain doesn't support it, see if the user has
  // registered+authenticated with a trusted third-party.
  var proxyAddr = http.get('https://trent.com/proxyAddr?email='+toEmailAddr + authCode);
  if (proxyAddr) {
    return OpenChatProto.deliver(proxyAddr, messageText);
  }

  // If the user doesn't exist in OpenChatProto, then
  // fallback to email.
  var emailText 
    = messageText
    + "To continue this discussion in real-time chat, go to:"
    + "https://trent.com/setup?email=" + toEmailAddr + authCode
    + "To block messages from this person, go to:"
    + "https://trent.com/optout?email=" + toEmailAddr + senderEmail + authCode
    + "To opt-out of all messages, go to:"
    + "https://trent.com/optout?email=" + toEmailAddr + authCode

  Email.deliver(toEmailAddr, emailText);

}

Note: It's most efficient if members of the federation agree on the identity of trent.com, but it's not required. Any outbound MTA could use a different Trent, but that fragments the brand and identity databases.

This feels pretty obvious, so maybe it's already being done or I'm missing something...

I am very much a novice, but here goes...

I don't think the paper was trying to speak to truncation generally. Truncation is a weakening of the crypto by definition. (Reduce bits => reduce security.) It is easier (cheaper) to find a collision if one uses a truncated hash. That doesn't make it Dangerous or Safe; just quantitatively reduced.

If the authors are trying to establish anything, it seems to be, "Yes, collisions do matter!"

As the Gnome-KDE bit unfolded, my first reaction was, "Guffaw! What a silly detail! That's not proving any thing. And no one would expect to bond with a stranger over that."

But that is not a flaw or limitation in the writing -- it's helping to characterize Tyrell as a bit of douche. This goes beyond the typical 'ssh' or 'wget' screengrab (which only provides some mechanistic plausibility in achieving a plot-point.). The Gnome-KDE bit defines character. It's brilliant.

I share your concern that this functionality could be abused, but disagree with your attempt to treat this as black-and-white or as a matter of personal character.

There are both ethical reasons and unethical reasons why an app-developer would want to know the other apps chosen by their users. On the up side, one could use the knowledge to prioritize improvements/integrations/compatibility with other apps. On the down side, one could punitively react to the presence of competing apps.

Assessing the ethics of how the functionality is used requires greater openness and transparency by everyone. Unfortunately, in a culture as closed as Apple's (eg http://www.pcmag.com/article2/0,2817,2375476,00.asp or https://developer.pidgin.im/wiki/WhyNoiOSVersion ), you are unlikely to see that kind of openness.

The probability of swarming would be influenced by multiple factors, eg

* Higher popularity => More peers => Higher probability that multiple peers want the same packfiles.

* Higher popularity => More commits => More permutations of packfiles => Lower probability that multiple peers want the same packfiles (and stronger trends toward small/inefficient packfiles).

* More frequent synchronizations (peers always online) => More immediacy => Smaller packfiles => Higher probability that multiple peers want the same packfiles.

* Less frequent synchronizations (peers go offline regularly) => Less immediacy => Bigger packfiles => Lower probability that multiple peers want the same packfiles.

It would be really interesting to see how these competing pressures play-out (either by doing some math or randomized experiments).

If the main goal here is strictly decentralization (without concern for performance or availability[F1]), then one might look at swarming as a nice-to-have behavior which only happens in some favorable circumstances. However, by latching onto the "torrent" brand, I think you setup some expectations for swarming/performance/availability.

([F1] Availability: If Seed-1 recommends a certain packfile, then the only peer which is guaranteed to have that packfile is Seed-1 -- even if there are many seeds with a full git history. If Seed-1 goes offline while transmitting that packfile, how could a leech continue the download from Seed-2? The #seeds wouldn't intuitively describe the reliability of the swarm... unless one adds some special-case logic to recover from unresolvable packfiles.)

---

Could this be mitigated with some constraints on how peers delineate packfiles?

"...non-idiomatic variable name casing (snake_case_in_ruby, camelCaseInJavaScript, dashes-in-lisp, scheme-predicates?, &c.)..."

That usage of "idiomatic" feels idiomatic to me. ;)

(I'd usually bite my tongue about such things, but your nic is picks_at_nits, and the thread is about the virtues of being pedantic...)

> If nobody understands a mathematical proof, does it count?

That depends. If it deals with integers, yes. If it deals with real numbers, no.

For many of these criticisms, can't we strike the balance by designing rules based on an individual's proxy-power (ie the #people for which they proxy). For example:

re:1) For any individual exercising a proxy-power <10, all votes are explicitly private. For any individual exercising proxy-power >=10, all votes are explicitly public.

re:2) Monitoring, transparency, ethics rules, etc increase in proportion with proxy-power.

re:3) Budget and staffing increase in proportion with proxy-power.

Additionally: Proxy-power is capped (e.g. 0.5% of national population). If you try to assign proxy-power to someone who has met the cap, then the assignment is rejected.

"Users apparently dislike this workflow so much that they don’t bother contributing at all: significantly less people are editing Wikipedia than did a few years ago."

To be fair, I think this exaggerates the role of the editing UI -- if the editing UI was that bad, then people wouldn't have contributed in the first place. The more common narrative for reduced participation is the growth of cultural issues which make it less rewarding to participate (e.g. http://www.technologyreview.com/featuredstory/520446/the-dec... ).

(Edit: Not trying to be negative -- the suggestions in the article sound cool anyway.)

Went to watch the July 4 fireworks in SF tonight, but it was cloudy, causing the fireworks to soften into a vague burst of color. I thought, "This looks just like CNN's coverage of the Gulf War. Except without all the fear and death. Damn, I'm lucky -- no war here!"

The article suggests that regulators will feel pressure to accept at least one major merger and reject at least one. Among them, a merger of #3+#4 wireless carriers (Sprint+TMobile) to form a new #3 seems less pernicious than a merger of #1+#2 cable operators (Comcast+TimeWarner) to form a new super-#1. (The ~40mil combined customers is almost 10x bigger than runner-up Cox's ~4.5mil.) My fear is that regulators could find the reverse conclusion by focusing on metrics that don't really reflect the competitiveness in each market.