I don't think it shows the number, but it does make suggestions from the list of tags you've already used. If you type out your tags manually it uses autocomplete so you don't end up with typos or fragmenting your stuff with minor variations (like making something plural half the time).
Google doesn't always find the thing I want, at least in the context of a bookmark, which is something specific that I want to return to. When I consult my bookmarks it's not necessarily to remember the broad strokes of a story, it's to read someone's take or even a specific line from an article that I only vaguely remember now that some time has passed, but suspect was really good. Sometimes Google gets me what I want, but often there are similar stories from larger sources that trump what I'm looking for.
Sometimes I feel like going back through things I liked (or have been meaning to read for a while) about a certain topic in bulk, so bookmarks with tags are nice. Querying Google to show me everything I've thought looked interesting about [x] won't work.
Sometimes you want something that isn't up anymore. Google has cached pages for lots of stuff but not everything. Pinboard will keep a copy of everything I bookmark.
You are correct on all points here. Stability and trust are very important in this market. Obviously, we are planning on being around for a long time, but it may take a little while for everyone to gain confidence in us. The best thing we can do is to keep iterating and prove that we are building something that's meant to last.
As far as building trust goes, we plan to automate the process of exporting your data soon, but until then we will provide it upon request at any point.
We also stick to open standards and open source software wherever possible so that your code is not dependent on any proprietary technology from us or anyone else. Our own server code is based completely on widely supported open source projects, ranging from Node to Redis.
Finally, we are open sourcing our own stack as aggressively as we can and already offer limited licenses to firms that are concerned about being dependent on our code.
In short, we're doing everything we can to ensure that you are never "locked in" to our technology or any one else's. Our goal is keep innovating so that you don't want to use another solutions.
I can see how this might seem like just another way to stand out, but I think in this case BaaS really is more descriptive than the other options. Platform-as-a-Service is a broad term that could reasonably contain what we do, in that we provide a platform from which to build applications. However, the idea of a PaaS is generally accompanied by the understanding that it involves deployment solutions and is more centered on providing the network, servers, etc. What we, and other companies using the BaaS title do, has much more to do with trying to provide backend and not just a platform to deploy your own stack to. It's a matter of focus, and while the title does help differentiate us from other services, I think it does so in an honest and helpful way.
I know this is the least satisfying support answer possible, but the chat appears to be available for me right now. I'd like to help figure out the problem, can you give me some details like your OS and browser?
One of our client projects involves having customer service staff talk and resolve payment issues with paying users. The messaging API means we have one less thing to worry about, allowing us to focus on handling payment resolution rather than the communication side of things.
I guess the idea is that these are utilities right?
You have msging and mention identity, assets storage...
So really this seems like it is heading toward the basic functionality of a CMS...
So... you might end up building some cloud-backed framework to demonstrate the bundle of APIs... that might not be your focus but people could build upon it...
Which is fine if that is what you want to do... another possibility is to branch into APIs covering novel functions.
Given your pricing model, seems you are going for widespread use that leans toward the more generic APIs...
I guess the question is... what do you want spire.io to be in the near future? That would dictate which APIs come next.
