On iOS9, iPhone6:
The comment box and comments overflow which require horizontal scrolling or zooming out. It worked better before simply because zooming in (double tap) is easier than zooming out (pinch).
Hyperledger's home page talks about a protocol, pools, consensus, security, and decentralization, however, none of those features exist in the codebase. Proof of work and distributed networks are why bitcoin and others are more complex than a list of node URLs and a simple database model.
After looking through code, a number of concerns are also raised:
- key pairs use RSA
- identities are based on MD5 of RSA public key
- no p2p protocol for nodes
- lack of proof of work (more on that below)
As-is, the project is a rails application which references accounts by MD5 of the public key, a postgresql database, and a REST client. In other words -- basic rails ledger app plus some PKI.
I see a significant issue with hyperledger, in that the pools are, by nature, private. The only verification a client can perform is the SSL certificate. A pool owner, if they wish, could change the account balance on all of their private nodes and there would be no public record of the change or the previous history. Yes this would require collusion of some kind, but even for 10k nodes, such data can be changed in seconds. Without a blockchain, how could anyone prove otherwise?
I see the potential for companies like quickbooks, paypal, or even banks, to create public REST interfaces for their account ledgers. This seems inexpensive for a bank to do (compared to a p2p network), and, we'd have the trust of the bank. This is money after all, so, I'd trust the bank over a psuedo-private network.
Looking forward to see how hyperledger will approach the problems described above. I would be surprised if the end-result isn't similar to bitcoin.
Thanks for your comments! There's obviously a bit of a gap between the proposed details and the implementation at the moment. Having said that, the framework for all of the features you mention are there at the moment, even if the implementation could do with some improving.
Our contention is that replicated HTTP services can provide a trustworthy base for a payments system, so the system is based on REST interfaces and signatures. There's no custom p2p protocol, it's just signed, broadcast HTTP messages. The current staging pool is running on 4 nodes and issuances and transactions aren't processed until at least 3 of them sign the message. The nice thing about signed HTTP messages is that there's a lot of infrastructure and tooling out there that can take advantage of this right off the bat.
The pools themselves aren't inherently private (although they could be, and at the moment we're the only ones running staging nodes) so there's not really a pool owner. Healthy, trustworthy pools should have nodes being run by completely disparate parties, and that's something we're working on getting running.
As for verification, all transfers and issuances are signed by the clients, and all requests are signed by the consensus nodes, and all of that information is public. The CLI doesn't really expose this very well and could definitely do with some work, but basically if queried, a node should be able to show the complete list of transactions that lead to a balance, each one signed by the clients and the nodes. If it can't do that, it's a misbehaving node and should be removed.
One thing that is missing in the code at the moment is primary/replica states and ordering of transactions. That's our next big chunk of work. Proof-of-work does a few things in Bitcoin, but ordering transactions is a big part of that and we think that a primary/replica system can do that without the overheads of proof-of-work.
Finally, I don't quite follow your concern about RSA public keys. I was thinking of moving to NaCl for keys/signatures, but that's an implementation detail at the moment and the protocol could support multiple algorithms. I think 2048-bit RSA keys is okay for now. MD5 signing of the public key is also an implementation detail and might be changed in the future, but I feel it's a pretty reasonable default to start with.
Hope that answers your concerns! Let me know if not.
Perhaps this could be good to introduce a little at a time. Like musical instruments (drum kits) or building blocks (legos). As a parent, I agree, that surrounding children with technology all the time can distract them from learning more important social skills. At the same time, I know my son is going to be asking me all the time "How does this work? How does that work? etc." And, unlike a software program, this provides a tactile experience which I think he'll be able to relate to when I say "Self driving cars work like your little robot".
LiveJournal doesn't route messages. It performs database queries which renders to HTML. As a result twitter will broadcast what you say to all of your followers, immediately, to their cell phones. This isn't something LiveJournal's architecture supported.
The patents involves routing messages with emphasis on followers. Everything previous I'm aware of has been multicast based or address based, like email or mailing lists. Most internet and application-layer protocols are destination based. Where is a protocol that says "Route this message based on who is interested in the source."? All I find is "send this message there, based on X, or, send that message here, based on Y"; both destination based. Would be interesting to know or hear of past protocols which are more similar to twitter's patent.
Everything previous I'm aware of has been multicast based or address based, like email or mailing lists.
As others remarked, IRC is follower-based. You follow a bunch of channels by sending subscription message (JOIN #channel-name) to central authority (IRC server). The server keeps track of who follows which channel, and brokers any PRIVMSG #channel message messages to the followers, until the person does PART #channel-name or disconnects. Aside of that, a direct person-to-person mechanism exists just as well, also via the PRIVMSG command.
The USER nickname command provides, among other, list of (public) channels the named person follows, which some IRC clients use to allow user to follow the same channels.
Yes, there is a difference between an IRC channel and a singular persona, but it is not as clear-cut as it may seem on its face. On one hand, some channels are muted, and only admins, or just a single admin, can post. On the other, Twitter handles often stand for multiple persons, speaking for one organization, team etc.
* * *
As an IRC user, I am ashamed and appalled of how low our industry has fallen -- somebody applies for a patent for what (after cursory read seems to me) a copy of well-known and long-established functionality.
IRC has no such long-established functionality. You can MSG a #channel or a user and that's it. User's can't follow each other and there are no lists. These followers and lists are how twitter routes messages, not a channel.
Such a simple difference makes all the difference. In this case, enough to file a patent.
If they didn't file a patent someone else would have.
This doesn't help adoption like the article suggests; what it does do is shave a few milliseconds and overhead off the initial connection which is great for thin or long pipes (low bandwidth or high latency). Otherwise, in contrast to the article's statement about SSL not being implemented because of the encryption overhead, false start doesn't change much.
The bigger picture is that false-start will make google's upcoming SPDY handshake faster too; then, because SPDY is a more aggressive with the initial connection (CWND, push support), the packets saved by false start are used to push content. Without false-start, an initial SPDY connection would be encumbered.
Depends on the investor. If he's big-time and busy then maybe it's best not to bother him with every piddling little detail. And this, I think, is a piddling little detail -- he doesn't care whether or not you're earning a few percent interest on his money, he cares about how fast you're turning it into fifty times his money.
As for the title of your question, sure, PHP/MySQL are stil practical. If the answer to your question were no, then that would mean companies like Facebook and Yahoo aren't practical.
With regard to your future decisions, you might strongly consider another language and framework, not because one is more practical than another, but because the developers behind that framework may have more of a propensity towards the context of your startup. So, for example, Ruby has a large web application community, Python has a large scientific community, and Java enterprise.
The primary contention behind PHP has largely been it's limited OO and speed, as compared to it's brethren interpreted languages. You can, creatively, do advanced things in PHP which are done in other languages, but it's not as straight forward and often clumsy or not supported. That said, PHP is simple enough that large implementations can easily modify PHP for their own use; considering how slow PHP's codebase moves, forward compatibility is far less of an issue.
All together I wouldn't base your decision on speed. Computing power is cheap now and all of them are feasible as far as speed is concerned. If you need to build something NOW, strongly considering going with what you know. If you have more time, consider writing something cliche like a multi-user blog or twitter platform with each framework -- you'll be exposed to patterns you haven't seen before and can also figure out what you like and don't like.
Unfortunately, this is a common response from upper management.
In larger companies, one way to get around this, is to go to Human Resources instead of your chain of command. Let them anonymously handle this issue. If your company doesn't take action then you can continue discussing the matter with HR until it's resolved.
If the company isn't large enough to have an employee handbook and HR then could report to an officer of the company and note that you wish to remain anonymous and that you're genuinely concerned about company security.
You could also consider requesting a meeting with officer+manager or HR+manager and disclose to both at the same time.
I don't see any company in their right mind firing you if you do this -- and are genuinely concerned for the security of your employer and it's clientele.
I would definitely not take this issue to HR. HR is not there to help you. Mostly, they're there to screw you out of a little bit more of your health insurance benefit every year. Escalating this above your manager is really just an opportunity to brand yourself "high drama".
You really ought to just have a conversation with your manager where you acknowledge that you have just learned that he doesn't want you testing the dev server for security vulnerabilities, and then you ask him what the most effective way is for the company to channel your interest in security.
