Implement read and create document endpoints.

[lukewhrit]

We need to implement two simple routes for creating and reading documents before this project can really go anywhere.

• [x] Read Document Endpoint
• [x] Create Document Endpoint

Each endpoint's purpose is very self descriptive.

One would be used for creating document's, with a body like:

{
    "content": "My content goes here"
}

The other would be used for reading a document's content. The only thing required is a key to find the document, this endpoint would return the document and it's key with a body like:

{
    "key": " ... ",
    "content: " ... "
}

When getting a document the key for the document being searched for would be provided in the body as "key".

I'd like to reiterate on how critical this is to implement, this is quite literally the core functionality of spacebin and MUST be completed before any other work is done.

[lukewhrit]

It's also very important that we get body validation in soon after these routes are implemented. Joi is fairly easy to use from what I remember so I think we can do this very easily.

[lukewhrit]

Also, I was going to have implemented this a while ago (at least partially) but was running into issues with Koa and status codes. If this issue comes back up we'll need to research it. It seemed like it was an issue with promises and Koa's built-in error handling.

[jackdorland]

perhaps change key to a UUID? perhaps id or uuid?

[lukewhrit]

perhaps change key to a UUID? perhaps id or uuid?

Sure, I can change to id.

[jackdorland]

UUID would leave room for stability into the future, mostly because of that sweet sweet 128-bits

[jackdorland]

quite frankly the only issue i see with having UUIDs is their length; but other than that, PGSQL can handle them, SQLITE can handle them

[jackdorland]

However that also means they're predictable.. No overflowing buffers, here.

[lukewhrit]

quite frankly the only issue i see with having UUIDs is their length; but other than that, PGSQL can handle them, SQLITE can handle them

The other issues is in urls, we don't want people sharing {x}.{x}/e973ba87-fba0-4fb5-8c7b-798caf4d68d.

[jackdorland]

well, quite frankly, UUIDs work quite well in URLs.. no extra characters, no user input.. just slightly more clunky

[lukewhrit]

UUID would leave room for stability into the future, mostly because of that sweet sweet 128-bits

Most instances will delete posts after some amount of time, and the length of the phonetic keys could always be changed.

well, quite frankly, UUIDs work quite well in URLs.. no extra characters, no user input.. just slightly more clunky

A lot more clunky.

Also, as far as I know every pastebin service uses a key generator similar to the one we're using.

[jackdorland]

Why not take Dean's approach and just make it an 8-char long psuedorandom string? could work well, and is quite stable

[jackdorland]

If we ever implement a key-based authentication system, UUIDs could be used well for the keys themselves.

[jackdorland]

Oh and: I'm making it a required goal of this project to be privacy conscious. Associated uploads will be opt-in; UUIDs are going to be anonymous, IDs won't be tied to users, no data stored.

[lukewhrit]

Why not take Dean's approach and just make it an 8-char long psuedorandom string? could work well, and is quite stable

That's pretty similar to what we are doing. I suppose I could make it exactly like that. And we can just use https://www.npmjs.com/package/randomstring

[jackdorland]

Sounds good, :suspect:

[lukewhrit]

Oh and: I'm making it a required goal of this project to be privacy conscious. Associated uploads will be opt-in; UUIDs are going to be anonymous, IDs won't be tied to users, no data stored.

Oh I was never going to associate uploads at all. I was going to store the number the document was (Auto-Incrementing ID), they identifier/key of the document, and the contents.

We could maybe take some inspiration from https://privatebin.net and also encrypt document contents with AES 256-bit.

But generally the service has no concept of users.

[jackdorland]

I was going to store the number the document was (Auto-Incrementing ID)

No incrementing IDs. Easily can be counted down and find other people's (perhaps private) uploads.

We could maybe take some inspiration from https://privatebin.net and also encrypt document contents with AES 256-bit.

Hell yeah! Perhaps password-encrypted could be a thing... we'll need to take Tom Scott's advice though, hashing and salting.

[lukewhrit]

I was going to store the number the document was (Auto-Incrementing ID)

No incrementing IDs. Easily can be counted down and find other people's (perhaps private) uploads.

These are only stored in the database, they're not accessible anywhere to the user. But I suppose we can easily remove them.

Especially since they serve no real purpose, other than I suppose analytics.

[jackdorland]

I think a good end-goal would be password-protected hashing/salting AES 256 encrypted pastes. perhaps the CLI could use -s or --encrypt

Hell, I could open a feature request about that for the long-term.

[lukewhrit]

I think a good end-goal would be password-protected hashing/salting AES 256 encrypted pastes. perhaps the CLI could use -s or --encrypt

Hell, I could open a feature request about that for the long-term.

Make a feature request and add it to the backlog?

[lukewhrit]

Implemented read document endpoint in c1d951b.

[lukewhrit]

Implemented create document endpoint in fabb87b