We are excited to announce that the Mozilla Corporation has completed the acquisition of Read It Later, Inc. the developers of Pocket.
Tag: silos
Break the logjam with a simple API
It just takes one storage service to decide to bridge the gap and a wonderful era of innovation can begin.
Background
Some people assume that for a user to be independent of silos, they would need to run a server. This is not true. With a tiny connection between JavaScript running in the browser and a cloud-based storage service, we can do anything a server can do without the server, entirely in the browser.
This isn't a question. In 2016, the technology is mature, we know how it works.
How to
Here's a sketch of how the service would work.
- Start with a user-facing service like Dropbox, Google Drive, Amazon Cloud Drive.
- Add an API that allows a JavaScript app running in the browser to write into a folder in a user's space. The user grants access via oAuth, as they do with Twitter, Facebook, etc.
- Connect to a registrar to allow a user to associate a domain name with a folder. Or map a domain they register elsewhere. A revenue opportunity.
That's it. Now I can hook my JS-in-the-browser app to your service. The user manages it through the UI you already support. And we've opened up a new area for developers to be creative. And most important, it says the exploration of great writing tools can advance outside of Medium. (That's how important Medium has been for the last few years.)
BTW, for Amazon, they would use the S3 API, which is supported everywhere. The apps would pop up very quickly for their service.
It's a total logjam and could be broken by one storage service deciding to help the users break free of silos.
Reply to Scott Kingery about Wallabag and Reading
Scott Kingery (TechLifeWeb)Chris, as a kind of sidebar to this, we talk about hosting things on our own site. I’ve always kind of thought this should be 1 piece of software we use for everything. I think that way becau…
Scott, as someone who’s studied evolutionary biology, I know that specialists in particular areas are almost always exponentially better at what they do than non-specialists. This doesn’t mean that we don’t need alternate projects or new ideas which may result in new “Cambrian explosions,” and even better products.
I also feel that one needs the right tool for the right job. While I like WordPress for many things, it’s not always the best thing to solve the problem. In some cases Drupal or even lowly Wix may be the best solution. The key is to find the right balance of time, knowledge, capability and other variables to find the optimal solution for the moment, while maintaining the ability to change in the future if necessary. By a similar analogy there are hundreds of programming languages and all have their pros and cons. Often the one you know is better than nothing, but if you heard about one that did everything better and faster, it would be a shame not to check it out.
This said, I often prefer to go with specialist software, though I do usually have a few requirements which overlap or align with Indieweb principles, including, but not limited to:
- It should be open, so I can modify/change/share it with others
- I should be able to own all the related/resultant data
- I should be able to self-host it (if I want)
- It should fit into my workflow and solve a problem I have while not creating too many new problems
In this case, I suspect that Wallabag is far better than anything I might have time to build and maintain myself. If there are bits of functionality that are missing, I can potentially request them or build/add them myself and contribute back to the larger good.
Naturally I do also worry about usability and maintenance as well, so if the general workflow and overhead doesn’t dovetail in with my other use cases, all bets may be off. If large pieces of my data, functionality, and workflow are housed in WordPress, for example, and something like this isn’t easily integrateable or very difficult to keep updated and maintain, then I’ll pass and look for (or build) a different solution. (Not every tool is right for just any job.) On larger projects like this, there’s also the happy serendipity that they’re big enough that WordPress (Drupal, Jekyll, other) developers can better shoehorn the functionality in to a bigger project or create a simple API thereby making the whole more valuable than the sum of the parts.
In this particular situation, it appears to be a 1-1 replacement for a closed silo version of something I’ve been using regularly, but which provides more of the benefits above than the silo does, so it seems like a no-brainer to switch.
To reply to this comment preferably do so on the original at: A New Reading Post-type for Bookmarking and Reading Workflow