Corporations do not so dissimilar things with teams of accountants and lawyers. Via tax planning, international subsidiaries and all other sorts of loopholes.
I'm equally hostile to corporations doing that. I don't recall the HN comment threats about Google doing the kind of things you describe being full of replies congratulating their ingenuity.
Big corporation doing bad thing is bad doesn't mean much smaller corporation doing bad thing is okay, it means we should work on preventing that bad thing and if we seemingly can't we should reconsider the underlying systemic conditions that enable it.
Same here. IPFS seems to have been lumped into the whole "crypto" scene because of filecoin. In my opinion, IPFS is much more interesting and potentially beneficial to individual freedom than crypto. The problem is the only people really talking about it are people focused on crypto, also forcing dapp conversations to focus on quick money vs. long term usability/functionality. I don't hold the money conversations against anyone...just not interested in that side of it. More interested in the preservation of knowledge long term and how/if that gets built. IPFS seems to be an interesting potential step towards those goals.
There's still a bunch of questions around filecoin, but if you set aside the token and speculative nature, the it's the first realistic proof of storage system and represents (1) a departure from proof of work that's sucking up the power output of several countries for no good reason,
(2) a useful base for IPFS to store its bits persistently
and (3) perhaps funding Protocol Labs so they can continue to advance this state of art.
Played around with it a few weeks ago. It was super easy to get going with it. I just dunno what benefits it gives over traditional storage? besides the classic crypto, "censorship resistant".
(Also hello HN, this is the first time I've posted anything :p )
I agree with you. And we also need technology like dApps that don't cost when running it by opcodes -with its vm, but use hourly pricing like cloud based hosting, so it will run your software deliberately without throw decentralized capabilities and it will enable decentralized economy to the mass.
Could you expand on what you mean by a variation of Signal? To me, Signal’s main feature is just that it’s a reliable E2E encrypted messaging app, implying two ends to communication. A blog post interface implies one-to-anyone communication, so I’m confused what part of Signal you want to emulate.
I am aiming for a decentralised-FB like experience on Signal. And I honestly think it is feasible.
On FB, you tag a post with intended recipients(default:All "Friends"), people log in and get fed these posts with FB fiddling along the way.
Signal with a redesigned UX could show a doom scroll of posts that friends send you. Not that I think this is great, but user adoption for familiarity.
Signal E2E delivers the message, the new UX displays the posts. You apply heuristics as you want, all without ads or data gathering by a MITM.
But... public posting is a thing. I am hoping that IPFS combined with cryptographic signing for authentication, could fill that role.
Hence my comment that IPFS could hopefully lead to democratization. Although, I am also concerned that IPFS will also lead to "undeletable" content, but that seems to be almost a thing anyway.
Scuttlebutt is the software you're looking for. Check out the patchwork client. Posts are public by default but you can make them encrypted so only your friends can read them.
There's also cabal chat which is based on the same underlying technology but is chat focused rather than Facebook like.
I keep seeing this pop up, but honestly I still don't get it. I'm also weirded out by the filecoin aspect of it. Could you maybe explain it better for the dumb folks like me?
Think of it as a distributed filesystem with content addressable by hash values. If you want to publish some content instead of posting a torrent file and seeding it, you can announce the content on IPFS to your IPFS peers. Anyone else can now find it by hash (or by name if you use IPNS). If anyone else downloads it, like with a torrent, they'll begin sharing it back out creating redundancy and, potentially, reducing access time for others as more people are sharing it out (imagine you're on a 10Mbps network connection and the only one sharing it versus having 100 others sharing it out, even if they're also all on 10Mbps connections it will be faster). Content can be "pinned" which ensures it remains on your IPFS node, if it's unpinned anything you download will eventually disappear (basically an LRU cache). So if you download the entire run of Dungeon Magazine but don't pin it, it will disappear if you continue downloading content via IPFS when the cache you've set aside for IPFS fills up (eventually). But if you pin it, the content will remain hosted by your node indefinitely, even if no one ever accesses it or pins it again and the original disappears.
Filecoin is a separate thing (mostly), and can (kind of) be thought of as pinning-as-a-service. It's built on a private IPFS network, not the main public one most people use or are directed to. So it's using IPFS, but it is not IPFS.
Is there a client that I can run and point at an existing file structure to make it all available on via IPFS? Perhaps with limiting on outgoing bandwidth?
I don't know of any, but I have been building prototypes in .NET Core 3+ that give me confidence in using this platform as a basis for an ultra-low-latency business system.
The biggest issue would be avoiding heap alloc, but that is actually not too difficult if you manage your data well enough. Most transactions in this business can be defined in terms of structs that are <1kb in size.
One other approach I have started to look at is sacrificing an entire high-priority thread to handling well-batched transactions (or extremely important timers) so that I never have to yield to the OS. In HFT, you always get an entire physical server to yourself, so eating 1 out of 32 threads is not a huge deal. In testing of this idea, I have found that I am able to reliably execute timers with accuracy of around 1/10th of a microsecond.
Java probably has more optimizations around GC suppression, but I feel like avoiding allocation in the first place is the most important bit. I believe there are already some ways to trick .NET into not running GC.
For now, I have been using this to test a toy/custom 2d client-server framework. All client events are piped to the server and processed in 1 gigantic ring buffer. This allows for ridiculous amounts of throughput due to batching effect. I am also using recurring, high-precision timers scheduled per client for purposes of triggering redraws and other important events as appropriate. This allows for complete decoupling of the event handling and client rendering pipelines. The breakdown is something like:
1 thread for ultra-low-latency timer execution
1 thread for processing the actual client event ring buffer, producing a consistent snapshot after each microbatch execution.
14+ threads for servicing HTTP requests (i.e. enqueuing client events), timers and redrawing client views using the near-real-time snapshots of business state.
My thinking is that if I can build something in this domain that is satisfactory, I could consider bringing it to an HFT firm as well.
Yes, this works. For now. The bigger problem is that this will probably go away at some point and the "sponsored" items will have no way (or a very difficult way) of being removed.
This has happened before with the browser toolbar having an about:config option to disable enlarging behavior, now you have to do some hacky CSS thing.
Now you don't just have to anticipate having options removed; that's the explicit development plan. (Quote is about a different preference, but I think it makes the style of development clear.)
> We intend to add a keyboard shortcut for this[1]. In the meantime you can revert to the old printing interface by setting the `print.tab_modal.enabled` preference to `false` via the page `about:config`. In a few releases time, after we've finished integrating user feedback and polishing rough edges, we intend to remove that preference though.
they plan to remove a hidden about:config preference for the system print dialog and replace it with a _dedicated keyboard shortcut_. if you think that's evidence that they want to take away your control, i beg to differ.
No, to be honest, I misread and thought that the final sentence meant that they were taking all configurability, both preference and keyboard shortcut, away.
I used Nanobox quite heavily before DO bought them.
But was a bit surprised when I saw the below, does this mean that they only payed $3,544 for the company? Or is there more to it than that?
> On April 4, 2019, the Company acquired 100% of the outstanding equity of Nanobox, Inc., a Delaware corporation (“Nanobox”), a deployment and management platform provider for cloud infrastructure. The final purchase price for Nanobox was $3,544 and the acquisition has been accounted for as a business combination.
Updated: 18 May 2020, 16:22:44 Password updated: 18 May 2020, 16:22:44 Password history: 1