Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft’s purchase of GitHub leaves some scientists uneasy

nature.com

Post reply on HN
Print view View original

141–148 of 148 posts

Re: Microsoft’s purchase of GitHub leaves some scientists uneasy

#141

Post by diggan »

kuon wrote: post #140
wolfgang42 wrote: post #121

Earlier quoted context omitted.

The one that seems to be gaining the most traction is IPFS[1]. /ipfs/ URLs are content-addressed (like git objects). As long as someone has a copy of the data somewhere on the IPFS network it will continue to be available, and if you manage to get a copy of the content from somewhere else you can try hashing it and make sure it matches. (And if it does you can `ipfs add` it and it will become available again, even if…

I should have added "human readable short persistent url". Like foo.com/xy/github where xy is an identifier as short as possible to avoid collision. And with ipfs you are dependent on the ipfs own domain. To remove domain dependency it would have to be something not based on current DNS system.

> And with ipfs you are dependent on the ipfs own domain

No, you might have gotten something wrong here. We (I work at Protocol Labs, I'm part of the development team working on IPFS) are hosting a public gateway you _can_ use but in no way have to use. You can either use your own local gateway, another gateway via IP or accessing the other peers gateways if that's accessible. Nothing is tied to the "ipfs.io" domain.

Re: Microsoft’s purchase of GitHub leaves some scientists uneasy

#142

Post by wolfgang42 »

kuon wrote: post #140
wolfgang42 wrote: post #121

Earlier quoted context omitted.

The one that seems to be gaining the most traction is IPFS[1]. /ipfs/ URLs are content-addressed (like git objects). As long as someone has a copy of the data somewhere on the IPFS network it will continue to be available, and if you manage to get a copy of the content from somewhere else you can try hashing it and make sure it matches. (And if it does you can `ipfs add` it and it will become available again, even if…

I should have added "human readable short persistent url". Like foo.com/xy/github where xy is an identifier as short as possible to avoid collision. And with ipfs you are dependent on the ipfs own domain. To remove domain dependency it would have to be something not based on current DNS system.

I'm not sure how well "short" and "decentralized" go together. The problem is that there's no good way to prevent someone from creating as many short identifiers as possible and taking them up forever. Distributed, maybe, if you have a central issuing authority who publishes a complete list that others can mirror and archive. I think this is what a DOI is supposed to be.

IPFS.io itself is an IPFS gateway, but you can resolve /ipfs/ paths without it if you run your own IPFS daemon; in fact this seems to be the end goal of the IPFS foundation, with ipfs.io being an stopgap measure since most people aren't running an IPFS daemon yet. The easiest way is to get this is to install the IPFS Companion browser plugin, which takes over resolution of ipfs.io and replaces it with a local gateway on your computer.

Re: Microsoft’s purchase of GitHub leaves some scientists uneasy

#143

Post by kuon »

diggan wrote: post #141
kuon wrote: post #140

Earlier quoted context omitted.

I should have added "human readable short persistent url". Like foo.com/xy/github where xy is an identifier as short as possible to avoid collision. And with ipfs you are dependent on the ipfs own domain. To remove domain dependency it would have to be something not based on current DNS system.

> And with ipfs you are dependent on the ipfs own domain No, you might have gotten something wrong here. We (I work at Protocol Labs, I'm part of the development team working on IPFS) are hosting a public gateway you _can_ use but in no way have to use. You can either use your own local gateway, another gateway via IP or accessing the other peers gateways if that's accessible. Nothing is tied to the "ipfs.io" domain.

Yes I understand how ipfs works. But I mean, now we don't have the ability to print an URL that is not dependent on a domain name ipfs or any other. That's why DNS would require an alternative for true persistent and decentralized identifiers that are human readable.

Re: Microsoft’s purchase of GitHub leaves some scientists uneasy

#144

Post by wolfgang42 »

kuon wrote: post #143
diggan wrote: post #141

Earlier quoted context omitted.

> And with ipfs you are dependent on the ipfs own domain No, you might have gotten something wrong here. We (I work at Protocol Labs, I'm part of the development team working on IPFS) are hosting a public gateway you _can_ use but in no way have to use. You can either use your own local gateway, another gateway via IP or accessing the other peers gateways if that's accessible. Nothing is tied to the "ipfs.io" domain.

Yes I understand how ipfs works. But I mean, now we don't have the ability to print an URL that is not dependent on a domain name ipfs or any other. That's why DNS would require an alternative for true persistent and decentralized identifiers that are human readable.

Well, of course you can't have a URL without a domain name; part of the spec for URLs is that they have a host part!

But, IPFS does not depend on the domain name system to keep your data accessible. You can install IPFS Companion to remove the dependency on the DNS system and ipfs.io gateway, replacing it with your own local gateway (so even if the IPFS Foundation goes away they will still work for anyone who has this set up). Or, you can look at the URL to find the hash and perform the lookup manually. There are also some discussions about making a new URI scheme, though I don't believe they've settled on anything yet.

As I've said in my other comment, I don't think that decentralized and human-readable are mutually compatible; if there is no central authority then how can it be decided when two people want the same name? If by first-come-first-serve, what prevents someone from squatting on all the good names? Namecoin for example solves this by requiring periodic renewal, but then you have the same problem that DNS has of link rot as names expire.

Re: Microsoft’s purchase of GitHub leaves some scientists uneasy

#145

Post by oaiey »

lucb1e wrote: post #72
oaiey wrote: post #53

Earlier quoted context omitted.

Microsoft is the number two cloud vendor. When they violate the privacy of their paying customers, they are dead. And no, telemetry is about privacy but not the same as reading the data/code itself.

> Microsoft is the number two cloud vendor. When they violate the privacy of their paying customers, they are dead. Perhaps it's different for paying customers, but I do have evidence of them scanning my OneDrive about ten year ago and them reading Skype chats about a year ago. I bet if someone uploads the OS X source code to OneDrive, or perhaps a private Github repository, the good parts of its design would somehow…

I think we should be more careful to distinguish between accessing data and "big data" usage like stats, ads, ... (and scanning illegal stuff). The later is "normal" business while the other is a real breach of trust.

Re: Microsoft’s purchase of GitHub leaves some scientists uneasy

#146

Post by OnlyRepliesToBS »

prepend wrote: post #88

The beauty of all this is that people can simply run their #openscience in Github and gitlab and bitbucket and (hopefully) their own gitea instance running on a $5/month digital ocean instance. It’s funny that this is a complaint about a company controlling a centralized resource because they worry. But any centralized resource has this risk. Did they think Github would lose money forever and subsidise infrastructure…

Like a frickin' ad.

Re: Microsoft’s purchase of GitHub leaves some scientists uneasy

#147

Post by kuon »

wolfgang42 wrote: post #144
kuon wrote: post #143

Earlier quoted context omitted.

Yes I understand how ipfs works. But I mean, now we don't have the ability to print an URL that is not dependent on a domain name ipfs or any other. That's why DNS would require an alternative for true persistent and decentralized identifiers that are human readable.

Well, of course you can't have a URL without a domain name; part of the spec for URLs is that they have a host part! But, IPFS does not depend on the domain name system to keep your data accessible. You can install IPFS Companion to remove the dependency on the DNS system and ipfs.io gateway, replacing it with your own local gateway (so even if the IPFS Foundation goes away they will still work for anyone who has thi…

Yeah, having an IPFS like system handled at the browser level (in the address bar) would solve the name resolving bit without DNS.

We could imagine something like this, the full URL is:

QmaG4FuMqEBnQNn3C8XJ5bpW8kLs7zq2ZXgHptJHbKDDVx/github/example.jpg

but could be written like so

Qx/github/example.jpg

And if there are duplicates, all duplicates are displayed in a list, with metadata (like creator, ssl info to help verify the creator...) and you select the one you want.

Re: Microsoft’s purchase of GitHub leaves some scientists uneasy

#148

Post by lucb1e »

oaiey wrote: post #145
lucb1e wrote: post #72

Earlier quoted context omitted.

> Microsoft is the number two cloud vendor. When they violate the privacy of their paying customers, they are dead. Perhaps it's different for paying customers, but I do have evidence of them scanning my OneDrive about ten year ago and them reading Skype chats about a year ago. I bet if someone uploads the OS X source code to OneDrive, or perhaps a private Github repository, the good parts of its design would somehow…

I think we should be more careful to distinguish between accessing data and "big data" usage like stats, ads, ... (and scanning illegal stuff). The later is "normal" business while the other is a real breach of trust.

I'm pretty sure they don't ban Skype accounts based on algorithms alone, seems risky.
Post reply on HN