eliotfowler/pigion-core

An open-source, share anything app for Mac OSX + Heroku + S3

Pigion

Note: I am practicing README-driven development. This README will serve as a general introduction to what this software will do when it is completed. This message will stay here until the software is in a usable state.

What is Pigion?

Pigion is a an app that allows you to quickly and easily share files with anyone.

Why?

We share stuff with each other all the time. The other day, I took so many screenshots that people thought the paparazzi had finally found out about my juggling skills.

Uhh, have you heard of Dropbox, man?

Dropbox isn't cool, you know what's cool? A billion Dropbox is pretty sweet, but they aren't a direct competitor right now. In fact, you can even use [Dropbox and Pigion](#I could use my Dropbox instead of hosting it on my own S3) together.

Without Pigion, this is how I accomplish sharing things:

1. Create file - take screenshot, write script, upload a photo from your camera, etc.
2. Open web browser and go to Imgur for images or Dropbox for everything else.
3. Get the link that I can send to people, either by clicking on the image in Imgur and then copying the URL or right clicking the file in Dropbox and clicking share.
4. Now that I have a link to that file, I can paste it anywhere I want - instant messaging, email, Yammer, Twitter, etc.

With Pigion, that workflow looks like this:

1. Create file - take screenshot, write script, upload a photo from your camera, etc.
2. Press the Cloud Copy keymap, currently Ctrl + Shift + C.
3. Now that I have a link to that file, I can paste it anywhere I want - instant messaging, email, Yammer, Twitter, etc.

Ctrl + Shift + C puts a link to any file you have locally on your clipboard that you can then paste in an email or IM, iMessage, ChatRoulette window, or anywhere else your heart desires.

This is cool, but I would only use it if...

###...I could password protect the files

You can.

###...I could make the file available for only a short amount of time

You can.

###...I could use my Dropbox instead of hosting it on my own S3

You can.

###...I could use my Google Drive instead of hosting it on my own S3

You can.

###...there was a quick way to generate a link to Rick Astly's Never Gonna Give You Up

Go away.

Active development

As I stated before, this project is in active development. This README was the first thing I created.

If this is the only file in the repo and the last commit was over 3 months ago, I probably abandoned it and forgot about it. Sorry.

About the author

If you like this, follow @EliotFowler on Twitter and let me know.

pigion-core's Issues

How should file uploading be handled?

There are going to be numerous clients - iOS, OS X, web, Windows, Android, Linux - uploading files that need to be managed by the Pigion server. For all intents and purposes, "storage" in this issue can be replaced with "S3 Bucket". There are two current approaches that are appealing to me at the moment:

Solution 1 - Upload from Client to Pigion, then from Pigion to Storage

This has the benefit of being able to process all files completely as they are being uploaded. It will be easy to monitor size restrictions as well as failed transfers. However, there will be a loss in efficiency as each chunk of each file will need to take 2 hops to get to its destination.

As the file is being streamed to the server, the chunks will be immediately passed on to the storage, so memory usage on the server will not be an issue.

Solution 2 - Send before and after requests to Pigion, then upload directly form Client to Storage

This solution is advantageous in terms of upload efficiency and implementation easiness, but it doesn't allow for as much control, at least it doesn't appear to.

In reality an approach like this would be a three step process:

First, a request will be made to Pigion with the file/user details to verify that uploading to the server shall be permitted.

For example, if the user had a filesize restriction and the requested file to be uploaded was too large, the request would be denied and the file would not be uploaded.

Assuming the request was granted, the file would be uploaded to the storage with a client-specific implementation.

Note: This is a disadvantage as each client becomes responsible for handling the direct interaction with the storage. With solution 1, Pigion could expose simple APIs such as:

POST: /files/upload/dropbox
POST: /files/upload/s3
POST: /files/upload/drive

The final step in solution 2 is notifying Pigion that the request finished. At this point, Pigion can move the file from a temporary directory to the users/directory and do any post-processing it requires.

Which approach makes more sense?

Whitelisted users

We need a way to have a list of users that are whitelisted to sign up. That way, with a public web app, people can't sign up at will and rack up huge charges on S3.

Cmd + Shift + D uploads to dropbox