Deprecated: Return type of I::current() should either be compatible with Iterator::current(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 62

Deprecated: Return type of I::next() should either be compatible with Iterator::next(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 91

Deprecated: Return type of I::key() should either be compatible with Iterator::key(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 71

Deprecated: Return type of I::valid() should either be compatible with Iterator::valid(): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 101

Deprecated: Return type of I::rewind() should either be compatible with Iterator::rewind(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 53

Deprecated: Return type of Collection::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/collection.php on line 80

Deprecated: parse_str(): Passing null to parameter #1 ($string) of type string is deprecated in /home/public/kirby/toolkit/lib/url.php on line 135
One Tap Less | Why file storage must be App.net's next step?

Why file storage must be App.net's next step?

Earlier this year, Dalton announced the File API for App.net, then paying members and developers got 10 gb of storage, while free tier accounts won 500 mb. Then, this week, Mat Honan wrote a great piece for Wired entitled The Great App.net Mistake, where it exposed the identity crisis of App.net.

Alpha was the first product out of the gate, launched in reaction to something Twitter did. Subsequently, much development was in building Twitter-like things. So its little wonder that people associate App.net with, well, Twitter. And once people form an idea of what a product is, it becomes very hard to change that idea.

The last sentence is the biggest truth, longer it takes for App.net to change how it present itself, harder it will be to do it. That's a branding issue. App.net is not only mistaken by a social network, it is mistaken by Alpha, its "Twitter-like" client. What App.net needs is the antithesis of a social network and, as I said in the first paragraph, the soil is ready for almost 1 year with the File Storage API.

Mat Honan, the writer of the Wired article, wrote a post that stung me:

And as to not posting more…. I haven't ever found a community here. I've tried. No, I haven't gone to great lengths, but, nor did I go to great lengths on other services, either. So I don't end up having discussions here. It is what it is.

What if this is the feeling most newcomers have when they join app.net?, I thought, because I felt like that, I joined App.net knowing nobody and I was lucky to be embraced by the community. And if you can't integrate socially within a social network, what is left for you? This is where file storage comes to play.

If App.net introduced a synced folder service for desktop, as Google Drive, Box, Copy and Dropbox does, it would give an alternative for users who can't find their tribe to keep using App.net.

Since the file storage would still be integrated with the social network, the user would still receive notifications whenever someone followed them and would be introduced to the social network little by little. As long as he kept using the service, whenever any of their actual friends join, they may be tempted to join the social network. It's the full circle.

Still, this wouldn't be enough. Following the Dropbox model, users would get more storage by inviting their friends. They would get more storage by linking their storage to the plethora of apps App.net offers. They would get more storage by reaching certain achievements related to the social network, like achieving X followers or X posts. The point being, they'd need to use the social network to receive file storage rewards.

But users could want to take a shortcut and pay for more storage, that creates another source of revenue. Looking at the market, there's no way for App.net to work without loss, so it better stick to the reality. Create a $10/month subscription for 100 gb storage and keep going up. Remember that paying members already have 10 gb storage.

Also, with the NSA leak, we know Dropbox is targeted to give your information away. Apple and Google already do it. If you want privacy, you should look for an alternative, the problem is integration, I can link several apps with Dropbox, I can't do it with Copy, for example. App.net could introduce a "mail drop" service in the meantime and just wait until developers create "clones" to cover basic functions of our common apps, such as note-taking. Picture yourself being able to play with several GTD applications having your tasks, projects, everything, transferred automatically. The File API does exactly that, we just need the right app.

If App.net wants to be the center of the date we own, the File API is the way to do it, not the social network. There's more to virtual life than interactions and conversations. In a nutshell, investing in file storage means creating a reason for users without friends already in the network to stick with it and a reason for these users to bring their friends in. It also creates another source of revenue and the timing is perfect due to the NSA leaks and how people are getting more concerned about their privacies. But beyond all that, it creates a product equivalent to Alpha and buries the "Twitter clone" identity App.net struggles to leave behind nowadays.