This repository has been archived on 2025-02-20. You can view files and clone it, but cannot push or open issues or pull requests.
Files
cavecomm/spec/spec.md
2023-06-05 18:28:54 +02:00

14 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

$id int - template id that automatically increments $freelancerID int - id referencing the freelancer who owns the template $name text - name of the template $content text - the main content describing the template $contactData text - contact data like discord username or email address $contactInformation text - supplemental contact information like email subject, or time availibility $currencyPreference text - Preference for currency provided. USD (or similar) for Stripe, Various shortening of crypto coins (such as BTC, ETH, XMR) for BTCPayServer. $priceUpFront decimal - The amount of money that the customer is to be charged before a freelancer starts working. $priceOnDeliver decimal - The amount of money that the customer is to be charged after the freelancer finishes working (required for payment-to-receive a product).

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.

modified Table structure

$id $customerName - name of customer $customerEmailAddress $customerContactDetails - extra details about contact or alternative contact options like discord $freelancerID - id referencing freelancer $templateID - id referencing template $currencyPreference $priceUpFront $priceOnDeliver $requestDescription $accepted boolean $upFrontInvoiceID $onDeliverInvoiceID $upFrontPaid $onDeliverPaid $completed - marker to set if the request has been completed

email delivery

email is sent via email server given by the admin, while the software functions as a client to it. https://hackernoon.com/how-to-implement-smtp-client-on-c

Interface

+++ Datatransfer inbetween pages is performed with POST

Customer

+++ /@{aliasName}

personal freelancer links that link to the freelancer profile and/or template

$aliasName text PRIMARY KEY - the name of the alias which is used for the route $freelancerID int - the id of the freelancer who created this alias $route text - route in the format "/customer/$freelancer/template/$templateName" set in the interface $routeParameter text - POST parameter to address the route usually the id of either freelancer or template $routeValue text - POST Value to address the route

+++ "/"

"/" 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.

+++ "/customer/$freelancer/template/$templateName/request"

request data partially provided by the template, gets filled out by the customer on this page.

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/aliasSetup"

A simple page for the selection of an alias and a destination which can be the profile or a specific template.

"/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" email + password +++ "/freelancer/logout" clears secure cookie and removes session from DB +++ "/freelancer/signup" creates user using a name, email and password while creating a salted hash of the password ++++ "/freelancer/login/passwordreset" Freelancer can request a reset email to be sent to an email

passwordResetKeys freelancerEmail text passwordResetKey text expiration timestamp - the time at which the resetkey is unusable.

+++ "/freelancer/profile" Profile page collating freelancer pages.

HTML Templates

HTML Templates are the raw HTML that is used, and filled in, by variable data provided by the system. Templates should be writen 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. The Templates should utilize purely lower-case variable names and all upper case for system variables like errors. Generic template snippets that are used in multiple templates via {{> x}} are located in templateIncludes in the format {name}{type}.html

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 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.

  • configuration file can be given as a parameter at startup else it is "cavecomm.conf".

must start with #configstart# and end with #configend#

comment #

{optionName}={optionValue}; Close variable with ;

mandatory: emailAddress emailPassword emailServerAddress databaseConnectionString={postgresql://{user}:{password}@{host}:{port}/{database}} domain

Optional if CROW_ENABLE_SSL not defined sslCrtPath= sslKeyPath=

optional:{default} emailServerPort={587} emailAddressDisplay={Cavecomm Automated Management System} regularTaskExecution={false} regularTaskExecutionIntervalSeconds={900} 15min regularTaskExecutionModules={} options separated by "|": bruteForceMitigationCleaner: Removes expired entries from the "loginLockOut" freelancerResetKeyCleaner: Removes expired entries from the "passwordResetKeys" itemsPerPage={0} 0 == no pagination bruteForceMitigationLockSeconds={900} 15min How long a login lock out is valid bruteForceMitigationAttempts={5} How many login attempts can be made until a login lock out is set submissionMaxFileSizeMB={4096} Filesize in MB; submissionMaxtotalStorageMB={131072} Filesize in MB; submissionMaxStorageDurationH={0} Duration in hours 0 = unlimited; submissionAllowedFiletypes={rar|zip|7z} Allowed file extensions like rar|zip|7z|webm|avi etc;