What I'm interested in, is how can they run this stuff? How is it cost effective for them? How is it safe? Runkit is basically free serverless node. It's pretty amazing.
- prepends a <base> element with the proxied page's uri ( to ensure relative links point to the source and not the proxy )
- prepends a script which captures clicks on anchor links and instead of allowing the navigation to proceed submits the URL ( via the prepended form ) back to the endpoint
Also, for the sake of a technical challenge, I don't know how to get it to work on Amazon.com -- what happens is after the first load, any links clicked seem to break out of the proxy. Anyone who can work out why it doesn't work, please tell me!
edit: oops, seems as if the HN 'glance' of death ( not hug, this has only been on for 20 minutes ) kills it intermittently, and that runkit has a quota that is sometimes exceeded!
> But if Facebook is bigger, newer, and weirder than a mere company, surely his trip is bigger, newer, and weirder than a mere presidential run. Maybe he’s doing research and development, reverse-engineering social bonds to understand how Facebook might better facilitate them. Maybe Facebook is a church and Zuckerberg is offering his benedictions. Maybe Facebook is a state within a state and Zuckerberg is inspecting its boundaries. Maybe Facebook is an emerging political community and Zuckerberg is cultivating his constituents. Maybe Facebook is a surveillance state and Zuckerberg a dictator undertaking a propaganda tour. Maybe Facebook is a dual power — a network overlaid across the U.S., parallel to and in competition with the government to fulfill civic functions — and Zuckerberg is securing his command. Maybe Facebook is border control between the analog and the digital and Zuckerberg is inspecting one side for holes. Maybe Facebook is a fleet of alien spaceships that have colonized the globe and Zuckerberg is the viceroy trying to win over his new subjects.
Exactly. It's like, Woah, hold your horses there. "Obsolete"? I don't think so. To what extent can this IPFS serve an API or a dynamic database at this point? To what extent will it ever be able to do that?
I think HTTP/websockets is very good for these things. Static data is one thing, dynamic is a whole other story. It seems IPFS is just a new distributed way to archive data. So what? It doesn't help serve something like FB over a distributed network does it?
And to what extent could some sort of "protocol" vulnerability stop these networks from being "uncensorable". Are they truly resistant to censorship, or could they be effectively shut down somehow? Wouldn't DDOS attacks cripple these? I mean, that's a crucial flaw, right, you just have to look up all nodes for an piece of content and constantly flood them with DDOS traffic and then, hey, you've censored the network, right?
In general? No.
Just because you can, it does not mean you should use a distributed db. Please remember to say that distributed, open databases have very narrow use cases.
Leaving aside use cases like credit card information, there are a lot of user information that is illegal to share unless the user explicitly consents. In the EU you can't even share your access logs by default.
And how do you handle authentication? Passwords? how do you avoid user enumeration, the collection of user email and info?
Distributed filesystems and CDN in general are great, but let's use them for things that do not actually need a single bit of security, please.
> "Distributed filesystems and CDN in general are great, but let's use them for things that do not actually need a single bit of security, please."
The notion that distributed filesystems are inherently, or can't be, secure is way off. I would argue that with these technologies, such as IPFS, they can be more secure.
The use cases are not only "open databases" (by which I assume you mean open to public), private databases and data sets can be achieved just as well. Just because it's "distributed" doesn't mean it can't be private or access controlled.
Agreed on the comment re. "...illegal to share unless the user explicitly consents" and I believe this will turn out better in the trustless, distributed web, eventually. Our whole current approach is based on the client-server paradigm forcing us to put every user and their data into one massive centralized database. But we can change the model here. Instead, how about you owning your data(base) and controlling who gets to access it? "Allow Facebook to read your social graph?" "Oh, no? How about another social network app?". As a user, I would want to have that choice.
That bridges to your next point on authentication, which can be done on the protocol level with authenticated data structures. You can define who can read/write to a database by using public key signing/verification. It could be just you, or it could be a set of keys. One good example of this is Secure Scuttlebut (http://scuttlebot.io/). I highly recommend to take a look an understanding the data structures underneath.
The problem is not that only authorized clients can write, that is the easy part (signatures are enough for that).
The problem is limiting read access. Having a globally distributed db means that anyone can get a copy.
You can use ipfs for public data, and to store private encrypted data (with caveats: make sure you change the encryption key/nonce for every data change).
There is no way to modify private data depending on anonymous access without things like omomorphic encryption, and the whole system is completely void of any form of forward secrecy.
As someone who works with encryption and security, I can not recommend storing anything private on distributed systems. Leaks way too much data, and there are too many caveats. You can have securely designed applications, but I see no way to safely port common websites completely on distributed infrastructure without leaking a lot of data that today is supposed to be kept secret.
Doesn't that make it completely pointless because updates are still centralised? It merely shifted trusting a single provider to trusting each user which is not a scalable solution.
The value add is so low you might as well just use IPNS and make people subscribe to IPNS addresses.
But it is scaleable. On scuttlebot you follow people just like you have friends in real life. I also don't need to ask the government permission to talk to that person. That is DEcentralized for you right there.
Think of orbitdb as a git repository where everyone has write access. Malicious nodes will spam hundreds of gigabytes of data into it until it's large enough nobody can clone it. Even if you solve the spam problem you still have the problem that you need to download the constantly growing dataset. The blockchain is already 160GB big even though it's transaction throughput is anemic.
Full p2p applications can't offload computation, computations have to happen on your computer and for computations you need the entire dataset. This is fine for messaging and static files.
Federation is a far better idea. You get the benefits of centralisation and decentralisation.
I'm concerned about the lack of type annotations. What about XSS prevention? Maintainability? An API? How are people supposed to use this code in future projects? Your variable names don't conform to Code Complete. This code smells funny. Haven't you read clean code? And I don't think it's general enough. What if people want to add columns, but preserve formulas? What made you think you shouldn't use React for this? At least Vue, come on.
ah, if only we could all code just what we needed, instead of over-engineering solutions to problems we wished we had
Yes! It's confusing seeing as it is the top comment but clearly everybody gets it and appreciated the joke. It's perhaps just too chillingly accurate ;).
All of the things you mentioned are best practices when building something that you want other people to use in production. The author was trying to build this with the absolute minimum amount of code as an exercise so I don't think any of your comments here apply.
Well, this spreadsheet as it is now isn't very much useful. In fact it is annoying at best. Only programmers will find it amusing and precisely because of how small the code is. No one is actually going to use it ever.
XSS prevention, maintainability, code reuse, good variable names, good-smelling code, readability, and using popular libraries are not "over-engineering". They are 95% of what makes someone a good employee instead of a shitty one.
With modern languages and tooling, you can have the benefits of most of these things at little-to-no additional cost. If any of these require something complicated and "over-engineered", I'd instead describe it as "bad engineering".
Rule one is making code that works correctly and quickly, in a short about of time. This is 100% of the job.
If you think that "maintainability" and "readability" and "popular" libraries, and "code reuse" and "good variable names" and code that "smells good" to you, help someone do that, then great: That's an argument we can have just by pointing to anyone who gets rule one without those things.
However.
There's another kind of person - and there's a lot of them - who thinks those things are important by themselves, and that putting those things ahead of what I think are rule one is ever acceptable.
The number of times I've heard some "experienced" programmer say with all earnestness that we should ask for another 1/4 million dollars of tin so that he can use his "clean" (but slow) algorithm makes me wary of anyone who uses those words you just used in seriousness.
> There's another kind of person - and there's a lot of them - who thinks those things are important by themselves, and that putting those things ahead of what I think are rule one is ever acceptable.
I think you totally understood my humor. Thanks!
I saw a good blog in 2011 about how it is a waste of time to overbuild things since mostly you are only ever going to use that code for the specific purpose you are writing it, and you'll likely never need to generalize and you'll probably chuck it out anyway and start from scratch.
Obviously there are a bunch of caveats to that and it's not always true that's the case but I think it's a very useful counterpoint to the profession's current best-practice obsession. If you keep it in mind, alongside all the best practices, and you make a choice about approach in any given situation based on appropriateness, rather than just robotically applying best practices or giving into that common Engineer's temptation to overbuild, this counterpoint can help you build quickly just what's needed, which is effective, exactly like you said.
I don't think those caveats are obvious to a junior (or otherwise inexperienced) developer. Maybe some of them are obvious, but I don't think anyone runs into these enough daily that programming by dogma actually helps.
And yet I do see value if there are rules! Why should we think about having "good variable names" or not if most of the time "good variable names" don't cause much harm, and most of the time not having them does?
It's just that I don't think this is a real problem; I don't believe anyone actually makes that choice.
I think if something doesn't have "good variable names" (as an example), then it's possible someone was programming who couldn't think of good ones (to which the rule wouldn't help anyway), and it's possible that these are good variable names, and that it's our opinion that is wrong (perhaps because we don't yet understand what we're looking at). NB) I'm not saying both are equally likely.
To put it another way, how can one recommend programming by brute force, "as long as you've got "readability" and "popular" libraries, and "code reuse" and "good variable names" and so on... What can we possibly add to that list that will be even a good substitute for a few decades of experience successfully delivering software?
I mean, security and maintainability is important, but the most secure and maintainable code is always the code that didn't get written in the first place, which makes not writing unnecessary code a no.1. way of making the result not suck.
Maybe the future history of the web will be Chinese made. Multiple independent app platform on Android there. Also if standardization is slow and mired by incumbent company interests maybe something capable of a unilateral forward thrust into a big Market will have success
I think org-mode is good. But I think that it and markdown could have better syntax for links. Like a link doesn't have to be wrapped in an opener or closer, since any spaces can be escaped. So you could simply do:
A main goal of Markdown is to be easy for anyone to use. Having to substitute characters in a URL string might be fairly trivial for you or me, but certainly not for everybody.
It's a trade off definitely. The way I think of it is, how often would you have to sub? Rarely. Since most uris do not have spaces, and even putting a URL in an address bar will usually sub it.
On the plus side, having a simpler syntax for URLs I feel is more readable which is great for ease of use. I think ~ looks like a link, and @ makes sense semantically.
But to be sure I think the legacy syntax could remain as a fallback / alternative. New syntax is something that could be tried in a flavor.
That's a good point. How do you create a "local working archive" of a website? It's a really good idea. Want to get started on working on some project like this?
Scrapbook extension for Firefox (one of the winners from either the first or second extension context IIRC) used to do this in a fantastic way.
You could download
- a page on it's own
- a page an all pages recursively for up to 3 levels
- optionally filtered by domain or path inside domain
- optionally including javascript (IIRC)
Sadly this is now broken in the new extension model and fixing it doesn't seem to be a priority.
Firefox is still my favourite browser by far but my enthusiasm isn't as strong as it used to be.
On the bright side even if it doesn't seem to be a priority work seems to progress on bringing the new extension APIs to a point where several of the old extensions can be recreated.
For those interested, the code is here: https://runkit.com/dosyago-coder-0/proxy
It does the simplest possible:
- prepends the URL form to the proxied html page
- prepends a <base> element with the proxied page's uri ( to ensure relative links point to the source and not the proxy )
- prepends a script which captures clicks on anchor links and instead of allowing the navigation to proceed submits the URL ( via the prepended form ) back to the endpoint
Also, for the sake of a technical challenge, I don't know how to get it to work on Amazon.com -- what happens is after the first load, any links clicked seem to break out of the proxy. Anyone who can work out why it doesn't work, please tell me!
edit: oops, seems as if the HN 'glance' of death ( not hug, this has only been on for 20 minutes ) kills it intermittently, and that runkit has a quota that is sometimes exceeded!