10 KiB
Concepts
Freelancer
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 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 freelancer's commissions will shut down. Templates - A list of templates that a freelancer uses.
Customer
Customers are any users of the site who do not hold an account. Ideally, they will be the ones purchasing labor from freelancers.
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. 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 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-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. $onDeliverInvoiceID - the ID of the invoice (for contacting BTCPayServer or Stripe). Set to N/a if not applicable. $upFrontPaid - A boolean representation of if the up-front Payment has been paid. $onDeliverPaid - A boolean representation of if the on-Deliver Payment has been paid.
Interface
Customer
"/"
"/" should return the main page of the site based off an HTML template provided to the program.
Ideally, the only interaction on this page will be with freelancer "Profiles", which may be selected by the end user to view more details about commissioning said person.
/customer/$freelancer/
This page should consist of all the information about a freelancer that the freelancer has decided to show. This includes contact information, pricing, templates, and anything else. Freelancers should be given a lot of sway with what they wish to put here.
See the freelancer section under concepts for more information of what this should be like.
/customer/$freelancer/template/$templateName
Accessing this page will provide the customer with a rendered HTML document of a freelancer's job template. This rendering will take data that the freelancer provides for the job, ideally stored in the database, and fills it in for delivery to the customer. The job template should use a html template that the system administrator provides for filling in.
The template provided should include an HTML form that submits information required in "/customer/$freelancer/template/$templateName/request" to "/customer/$freelancer/template/$templateName/request". This is not necessary, for flexability reasons, but will be the system Cavemanon uses for their commission requests.
"/customer/$freelancer/template/$templateName/request"
A customer who wishes to request a freelancer with an open template must provide an email address, a name, and a description. Optionally, the user may provide auxiliary contact information (such as a Discord account, a Skype account, a Matrix account, a Github account, etc.). This information should be stored in a database of commission requests. A request should also be emailed out to the freelancer.
Freelancer
"/freelancer/inbox"
The inbox will be a simple list representation of commissions a freelancer has, ideally highlighting new ones. This web interface need not be complex for the back-end work currently, but it should be able to easily be stylized with simple CSS.
"/freelancer/inbox/$requstID"
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 a freelancer is interested in $requestID.
Acceptance will change the $accepted value for $requestID to true.
"/freelancer/requests/$requestID/decline"
Sending a request to this endpoint will tell the back end that a freelancer is not interested in $requestID.
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.
"/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 should be used. In the case of Stripe, the transaction should use the multiparty payout system. 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.