everything except login has been completed spec-wise
This commit is contained in:
86
spec/spec.md
86
spec/spec.md
@ -5,11 +5,11 @@
|
||||
|
||||
Freelancers are users of the site who hold accounts on the site. These users will sell labor through the site. Freelancers will store Stripe account information and crypto wallet addresses for payment.
|
||||
|
||||
Freelancers will have "profiles" of data they wish to display to the public. This data should be very maluable, ideally consisting of a plain text description along with a freelancer-defined Key-Pair for information.
|
||||
Freelancers will have "profiles" of data they wish to display to the public. This data should be very malleable, ideally consisting of a plain text description along with a freelancer-defined Key-Pair for information.
|
||||
|
||||
Freelancers ought to be pure data. They should include:
|
||||
|
||||
Commission Limit - The maximum amount of commissions that a freelancer wishes to take. Once this limit is reached, a freelancher's commissions will shut down.
|
||||
Commission Limit - The maximum amount of commissions that a freelancer wishes to take. Once this limit is reached, a freelancer's commissions will shut down.
|
||||
Templates - A list of templates that a freelancer uses.
|
||||
|
||||
|
||||
@ -19,18 +19,20 @@ Customers are any users of the site who do not hold an account. Ideally, they wi
|
||||
|
||||
## Templates
|
||||
|
||||
Templates are prepared and defined descriptions of jobs, with payments, that Freelancers furnish and offer to the public. They are easy, cookie cutter listings that the public may purchase for a predefined amount of money.
|
||||
Templates are prepared and defined descriptions of jobs, with payments, that Freelancers furnish and offer to the public. They are easy, cookie cutter listings that the public may purchase for a predefined amount of money. These are effectively "canned" jobs with cookie cutter definitions and little need for communication between client and freelancer as to offer a streamlined commissioning experience.
|
||||
|
||||
For example, a template for an artist may be a $50, one character, full body, full color image. A customer may request that, provide a description, and a freelancer can accept or deny the deal (or contact the customer for more details).
|
||||
|
||||
## Commission Request Database
|
||||
|
||||
This database will house all commissions that take place on the site. Each entry must have the following data:
|
||||
$requestID - A unique ID given to the request. Likely can be increimental.
|
||||
$requestID - A unique ID given to the request. Likely can be incremental.
|
||||
$customerEmailAddress - The Customer's email address
|
||||
$freelancer - The requested freelancer
|
||||
$templateName - The Template name, if any, that is being used. N/A Otherwise.
|
||||
$currencyPreference - Preference for currency provided. USD (or similar) for Stripe, Various shortening of crypto coins (such as BTC, ETH, XMR) for BTCPayServer.
|
||||
$priceUpFront - The amount of money that the customer is to be charged before a freelancer starts working.
|
||||
$priceOnDeliver The amount of money that the customer is to be charged after the freelancer finishes working (required for payment-to-recieve a product).
|
||||
$priceOnDeliver The amount of money that the customer is to be charged after the freelancer finishes working (required for payment-to-receive a product).
|
||||
$requestDescription - The description of the request.
|
||||
$accepted - If the freelancer has accepted to do a request or not. Ideally has three states, true, false, and undecided, but two should suffice.
|
||||
$upFrontInvoiceID - the ID of the up front invoice (for contacting BTCPayServer or Stripe). Set to N/a if not applicable.
|
||||
@ -75,13 +77,79 @@ This will show the actual formatted message that $requestID contains.
|
||||
|
||||
### "/freelancer/requests/$requestID/accept"
|
||||
|
||||
Sending a request to this endpoint will tell the back end that
|
||||
Sending a request to this endpoint will tell the back end that a freelancer is interested in $requestID.
|
||||
|
||||
Acceptance will change the $accepted value for $requestID to true.
|
||||
|
||||
### "/freelancer/requests/$requestID/decline"
|
||||
|
||||
### POST
|
||||
Sending a request to this endpoint will tell the back end that a freelancer is not interested in $requestID.
|
||||
|
||||
# HTML Template
|
||||
Acceptance will change the $accepted value for $requestID to false. Declining will also tell the Email server to send a declining letter to the requester.
|
||||
|
||||
HTML Templates should be able to access loaded data of freelancers through some type of variable name. An HTML Assembler should then fill in the variable with any requested data.
|
||||
### "/freelancer/createInvoice"
|
||||
|
||||
There are times that a freelancer may wish to send a custom invoice to a customer, such as after making a quote for a custom commission. Freelancers should be able to fill out a simple form to create a custom invoice on behalf of a user. The back-end of these invoices should be identical to ones created by requests. Invoices created by freelancers should have $accepted set to true automatically upon creation.
|
||||
|
||||
### "/freelancer/login"
|
||||
TODO: Figure out what to do for this.
|
||||
|
||||
# HTML Templates
|
||||
|
||||
HTML Templates are the raw HTML that is used, and filled in, by variable data provided by the system. Templates should be wrote and saved on the file system of the hosting computer, and loaded upon start up. These loaded templates should be filled in with data provided by the system, then the assembled HTML should be given as a response to users.
|
||||
|
||||
|
||||
# Payment Verification
|
||||
|
||||
## Upfront
|
||||
Upfront-related processes will only be triggered in situations where there is an attached price up front. Otherwise, this can be ignored.
|
||||
|
||||
### UpFrontPaymentSetup
|
||||
|
||||
The UpFrontPaymentSetup system will watch poll the commission database for new, approved commissions. Given the context of the commission (such as using Stripe or BTCPayServer), the UpFrontPaymentServer will contact the payment gateway and request an invoice set up. From there, the Invoice ID will be saved to the commission database.
|
||||
|
||||
### UpFrontPaymentWatcher
|
||||
|
||||
This will send periodic queries to the provider of $invoiceID for $invoiceID's status. Once payment has been received, the Freelancer will be sent an email alert containing notification that they are free to start working. Along with this, an email to the customer (and the freelancer) will be distributed as well.
|
||||
|
||||
# delivery
|
||||
|
||||
### deliveryHandler
|
||||
|
||||
The Delivery handler will wait for a freelancer to upload the contents of a commission "/freelancer/$freelancer/requests/$requestID/finalProduct". Once this happens (or a freelancer marks that delivery was done through out-of-platform means, such is in labor), the delivery handler check if the upFront is paid (if applicable), and, if the onDeliver is paid (if applicable). If both are true, then the delivery process will commence.
|
||||
|
||||
If the freelancer uploaded content to the service, then the link generation process will commence.
|
||||
|
||||
## Link Generation
|
||||
|
||||
Link generation will provide the freelancer with a URL that links to the uploaded content. This link should be temporary, expiring after 1 week. This link will be useful for distributing commissions to a client via non-email means, or if the client is unable to receive the email from the email server.
|
||||
|
||||
## onDeliver
|
||||
|
||||
onDeliver-related processes will only be triggered in situations where there is an attached price to the delivery of a product. Otherwise, this can be ignored.
|
||||
|
||||
### onDeliverPaymentSetup
|
||||
|
||||
If the deliveryHandler notices that payment-on-deliver will be necessary to complete a transaction, the onDeliverPaymentSetup will create an invoice, similar to upFrontPaymentSetup, and issue it to the customer.
|
||||
|
||||
### onDeliverPaymentWatcher
|
||||
|
||||
Similar to the upFrontPaymentWatcher, the onDeliverPaymentWatcher will poll the payment gateway for the status of the invoice. Once paid, the Freelancer will be notified that the payment for the commission has been received, and the delivery process will be triggered.
|
||||
|
||||
## Delivery Process
|
||||
|
||||
Standard procedure for delivery is to email out the uploaded contents of a delivery to the end user.
|
||||
|
||||
# Commission Queue
|
||||
|
||||
Freelancers may wish to limit the amount of work they receive as to not be overwhelmed. Freelancers should have a self-set maximum number of jobs taken globally, and a maximum number of jobs set per-template. Once this limit is reached, all pending commissions will not be able to be accepted, only rejected, and people who have sent in a request will receive an email that, for now, commissions for their requested freelancer will be closed.
|
||||
|
||||
Freelancer created invoices will not be limited through this method, however, they will count to the total number of global jobs being done.
|
||||
|
||||
# Monetary Payouts
|
||||
|
||||
Monetary payouts will be handled through the payment gateways provided. For now, when a freelancer accepts payment in a currency (rather that's through stripe or crypto), they'll get that money through the respective platform. If a client pays for a commission in crypto, the freelancer will receive crypto.
|
||||
|
||||
This means that, in the case of BTCPayServer, the [payout system](https://docs.btcpayserver.org/Payouts/) should be used. In the case of Stripe, the transaction should use the [multiparty payout system](https://stripe.com/docs/connect/add-and-pay-out-guide). Both will require a central, authoritative set of accounts respectively to shuffle money between client and freelancer.
|
||||
|
||||
This authoritative account, by default, should give 97% of a commission's value to the freelancer, with the 3% being reserved for itself as a service fee. This ratio should be able to be edited by the system's administrator.
|
||||
|
Reference in New Issue
Block a user