A few of you have wondered what’s the deal with that.
This post covers why this effort stalled, what I’m proposing we do next.
What’s The Hold Up?
The “easy” (relatively speaking) parts of the problem are as follows:
Secret key management. (This is sketched out already, and provides multiple mechanisms for managing secret key material. Yay!)
Bulk encryption of messages and media. (I’ve done a lot of work in this space over the years, so it’s an area I’m deeply familiar with. When we get to this part, it will be almost trivial. I’m not worried about it at all.)
Forward-secure ratcheting / authenticated key exchange / group key agreement. (RFC 9420 is a great starting point.)
That is to say, managing secret keys, using secret keys, and deriving shared secret keys are all in the “easy” bucket.
In a centralized service (think: Twitter, Facebook, etc.), this is actually much easier to build: Shove your public keys into a database, and design your client-side software to trust whatever public key your server gives them. Bob’s your uncle, pack it up and go home.
Unfortunately, it’s kind of stupid to build anything that way.
If you explicitly trust the server, the server could provide the wrong public key (i.e., one for which the server knows the corresponding secret key) and you’ll be none the wiser. This makes it trivial for the server to intercept and read your messages.
If your users are trusting you regardless, they’re probably just as happy if you don’t encrypt at the endpoint at all (beyond using TLS, but transport encryption is table stakes for any online service so nevermind that).
You could improve endpoint trust by shoving all of your users’ public keys into an append-only data structure; i.e. key transparency, like WhatsApp proposed in 2023:
And, to be perfectly clear, key transparency is a damn good idea.
Key transparency keeps everyone honest and makes it difficult for criminals to secretly replace a victim’s public key, because the act of doing so is unavoidably published to an append-only log.
The primary challenge is scaling a transparency feature to serve a public, federated system.
Despite appearances, I haven’t been sitting on my thumbs for the past year or so. I’ve been talking with cryptography experts about their projects and papers in the same space.
Truthfully, I had been hoping to piggyback off one of those upcoming projects (which is focused more on public key discovery for SAML- and OAuth-like protocols) to build the Federated PKI piece for E2EE for the Fediverse.
Unfortunately, that project keeps getting delayed and pushed back, and I’ve just about run out of patience for it.
Additionally, there are some engineering challenges that I would need to tackle to build atop it, so it’s not as simple as “let’s just use that protocol”, either.
This will not only be useful for building a coherent specification for E2EE (as it provides the “Federated PKI” component we’d need to build it securely), but it would also be extremely useful for software developers the whole world over.
Imagine this:
If you want to fetch a user’s SSH public key, you can just query for their username and get a list of non-expired, non-revoked public keys to choose from.
If you wanted public key pinning and key rotation for OAuth2 and/or OpenID Connect identity providers without having to update configurations or re-deploy any applications, you can do that.
If you want to encrypt a message to a complete stranger, such that only they can decrypt it, without any sort of interaction (i.e., they could be offline for a holiday and still decrypt it when they get back), you could do that.
Oh, and best of all? You can get all these wins without propping up any cryptocurrency bullshit either.
From simple abstractions, great power may bloom.
Mark Miller
How Will This Work?
We need to design a specific kind of server that speaks a limited set of the ActivityPub protocol.
I say “limited” because it will only not support editing or deleting messages provided by another instance. It will only append data.
To understand the full picture, let’s first look at the message types, public key types, and how the message types will be interpreted.
Message Types
Under the ActivityPub layer, we will need to specify a distinct set of Directory Message Types. An opening offer would look like this:
[strong]AddKey[/strong] — contains an Asymmetric Public Key, a number mapped to the user, and instance that hosts it, and some other metadata (i.e., time)
[strong]RevokeKey[/strong] — marks an existing public key as revoked
[strong]MoveIdentity[/strong] — moves all of the public keys from identity A to identity B. This can be used for username changes or instance migrations.
We may choose to allow more message types at the front-end if need be, but that’s enough for our purposes.
Public Key Types
We are not interested in backwards compatibility with every existing cryptosystem. We will only tolerate a limited set of public key types.
At the outset, only Ed25519 will be supported.
In the future, we will include post-quantum digital signature algorithms on this list, but not before the current designs have had time to mature.
ECDSA over NIST P-384 may be included at some point, if there’s sufficient interest in supporting e.g., US government users.
If ECDSA is ever allowed, RFC 6979 is mandatory.
Message Processing
When an instance sends a message to a Directory Server, it will need to contain a specific marker for our protocol. Otherwise, it will be rejected.
Each message will have its own processing rules.
After the processing rules are applied, the message will be stored in the Directory Server, and a hash of the message will be published to a SigSum transparency ledger. The Merkle root and inclusion proofs will be stored in an associated record, attached to the record for the new message.
Every message will have its hash published in SigSum. No exceptions.
We will also need a mechanism for witness co-signatures to be published and attached to the record.
Additionally, all messages defined here are generated by the users, client-side. Servers are not trusted, generally, as part of the overall E2EE threat model.
The first AddKey for any given identity will need to be self-signed by the key being added (in addition to ActivityPub messages being signed by the instance).
After an identity exists in the directory, every subsequent public key MUST be signed by a non-revoked keypair.
Directory Servers should be configurable to mirror records from other instances.
Additionally, they should be configurable to serve as Witnesses for the SigSum protocol.
The communication layer here between Directory Servers will also be ActivityPub.
Preventing Abuse
The capability of learning a user’s public key doesn’t imply the ability to send messages or bypass their block list.
Additionally, Fediverse account usernames are (to my knowledge) generally not private, so I don’t anticipate there being any danger in publishing public keys to an append-only ledger.
That said, I am totally open to considering use cases where the actual identity is obfuscated (e.g., HMAC with a static key known only to the instance that hosts them instead of raw usernames).
What About GDPR / Right To Be Forgotten?
Others have previously suggested that usernames might be subject to the “right to be forgotten”, which would require breaking history for an append-only ledger.
After discussing a proposed workaround with a few people in the Signal group for this project, we realized complying necessarily introduced security issues by giving instance admins the capability of selectively remapping the user ID to different audiences, and detecting/mitigating this remapping is annoying.
However, we don’t need to do that in the first place.
However, an organization’s right to process someone’s data might override their right to be forgotten. Here are the reasons cited in the GDPR that trump the right to erasure:
(…)
The data is being used to perform a task that is being carried out in the public interest or when exercising an organization’s official authority.
(…)
The data represents important information that serves the public interest, scientific research, historical research, or statistical purposes and where erasure of the data would likely to impair or halt progress towards the achievement that was the goal of the processing.
Enabling private communication is in the public interest. The only information that will be stored in the ledger in relation to the username are cryptographic public keys, so it’s not like anything personal (e.g., email addresses or legal names) will be included.
However, we still need to be extremely up-front about this to ensure EU citizens are aware of the trade-off we’re making.
Account Recovery
In the event that a user loses access to all of their secret keys and wants to burn down the old account, they may want a way to start over with another fresh self-signed AddKey.
However, the existing policies I wrote above would make this challenging:
Since every subsequent AddKey must be signed by an incumbent key, if you don’t have access to these secret keys, you’re locked out.
Since RevokeKey requires one trusted keypair remains in the set, for normal operations, you can’t just burn the set down to zero even while you still had access to the secret keys.
There is an easy way out of this mess: Create a new verb; e.g. BurnDown that an instance can issue that resets all signing keys for a given identity.
The use of BurnDown should be a rare, exceptional event that makes a lot of noise:
All existing E2EE sessions must break, loudly.
All other participants must be alerted to the change, through the client software.
Witnesses and watchdog nodes must take note of this change.
This comes with some trade-offs. Namely: Any account recovery mechanism is a backdoor, and giving the instance operators the capability of issuing BurnDown messages is a risk to their users.
Therefore, users who trust their own security posture and wish to opt out of this recovery feature should also be able to issue a Fireproof message at any point in the process, which permanent and irrevocably prevents any BurnDown from being accepted on their current instance.
If users opt out of recovery and then lose their signing keys, they’re locked out and need to start over with a new Fediverse identity. On the flipside, their instance operator cannot successfully issue a BurnDown for them, so they have to trust them less.
Notice
This is just a rough sketch of my initial ideas, going into this project. It is not comprehensive, nor complete.
There are probably big gaps that need to be filled in, esp. on the ActivityPub side of things. (I’m not as worried about the cryptography side of things.)
How Will This Be Used for E2EE Direct Messaging?
I anticipate that a small pool of Directory Servers will be necessary, due to only public keys and identities being stored.
Additional changes beyond just the existence of Directory Servers will need to be made to facilitate private messaging. Some of those changes include:
Some endpoint for users to know which Directory Servers a given ActivityPub instance federates with (if any).
Some mechanism for users to asynchronously exchange Signed Pre-Key bundles for initiating contact. (One for users to publish new bundles, another for users to retrieve a bundle.)
These will be Ed25519-signed payloads containing an ephemeral X25519 public key.
This is all outside the scope of the proposal I’m sketching out here today, but it’s worth knowing that I’m aware of the implementation complexity.
The important thing is: I (soatok@furry.engineer) should be able to query pawb.fun, find the Directory Server(s) they federate with, and then query that Directory server for Crashdoom@pawb.fun and get his currently trusted Ed25519 public keys.
From there, I can query pawb.fun for a SignedPreKey bundle, which will have been signed by one of those public keys.
Okay, so that was a lot of detail, and yet not enough detail, depending on who’s reading this blog post.
What I wrote here today is a very rough sketch. The devil is always in the details, especially with cryptography.
Goals and Non-Goals
We want Fediverse users to be able to publish a public key that is bound to their identity, which anyone else on the Internet can fetch and then use for various purposes.
We want to leverage the existing work into key transparency by the cryptography community.
We don’t want to focus on algorithm agility or protocol compatibility.
We don’t want to involve any government offices in the process. We don’t care about “real” identities, nor about codifying falsehoods about names.
We don’t want any X.509 or Web-of-Trust machinery involved in the process.
Tasks
The first thing we would need to do is write a formal specification for a Directory Server (whose job is only to vend Public Keys in an auditable, transparent manner).
Next, we need to actually build a reference implementation of this server, test it thoroughly, and then have security experts pound at the implementation for a while. Any security issues that can be mitigated by design will require a specification update.
We will NOT punt these down to implementors to be responsible for, unless we cannot avoid doing so.
Once these steps are done, we can start rolling the Directory Servers out. At this point, we can develop client-side libraries in various programming languages to make it easy for developers to adopt.
My continued work on the E2EE specification for the Fediverse can begin after we have an implementation of the Directory Server component ready to go.
Timeline
I have a very demanding couple of months ahead of me, professionally, so I don’t yet know when I can commit to starting the Fediverse Directory Server specification work.
Strictly speaking, it’s vaguely possible to get buy-in from work to focus on this project as part of my day-to-day responsibilities, since it has immediate and lasting value to the Internet.
However, I don’t want to propose it because that would be crossing the professional-personal streams in a way I’m not really comfortable with.
The last thing I need is angry Internet trolls harassing my coworkers to try to get under my fur, y’know?
If there is enough interest from the broader Fediverse community, I’m also happy to delegate this work to anyone interested.
Once the work can begin, I don’t anticipate it will take more than a week for me to write a specification that other crypto nerds will take seriously.
I am confident in this because most of the cryptography will be constrained to hash functions, preventing canonicalization and cross-protocol attacks, and signatures.
Y’know, the sort of thing I write about on my furry blog for fun!
Building a reference implementation will likely take a bit longer; if, for no other reason, than I believe it would be best to write it in Go (which has the strongest SigSum support, as of this writing).
This is a lot of words to say, as far as timelines go:
Regardless of whether my overall E2EE proposal gets adopted, the Directory Server component is something that should be universally useful to the Fediverse and to software developers around the world.
The public key directory server’s specification will eventually exist in this GitHub repository.
Can I Contribute Non-Technically?
Yes, absolutely. In the immediate future, once it kicks off, the work is going to be technology-oriented.
However, we may need people with non-technical skills at some point, so feel free to dive in whenever you feel comfortable.
What About Financially?
If you really have money burning a hole in your pocket and want to toss a coin my way, I do have a Ko-Fi. Do not feel pressured at all to do so, however.
Because I only use Ko-Fi as a tip jar, rather than as a business, I’m not specifically tracking which transaction is tied to which project, so I can’t make any specific promises about how any of the money sent my way will be allocated.
What I will promise, however, is that any icons/logos/etc. created for this work will be done by an artist and they will be adequately compensated for their work. I will not use large-scale computing (a.k.a., “Generative AI”) for anything.
Closing Thoughts
What I’ve sketched here is much simpler (and more ActivityPub-centric) than the collaboration I was originally planning.
Thanks for being patient while I tried, in vain, to make that work.
As of today, I no longer think we need to wait for them. We can build this ourselves, for each other.
Also known as the right to erasure, the GDPR gives individuals the right to ask organizations to delete their personal data. But organizations don’t always have to do it....
A frequent source of confusion in the furry fandom is about commission pricing for furry art.
This confusion is often driven by (usually younger) furries demanding free or severely cheap art from artists, and the aftermath of such exchanges. There’s a reason @SpicyFurryTakes posts so frequently.
In the interest of not adding to the confusion, I’d like to offer a simple algorithm for artists to use for their standard commission prices, and then some guidelines for artists and commissioners to make the art commissioning experience better for everyone.
As my goal here is to simplify, I will be taking liberties and eschewing a lot of the economic details. If you feel that I made a mistake but aren’t sure because I’m not showing my work, feel free to leave a comment.
If you’re an artist reading this, you should almost certainly raise your rates.
Furry artists in particular are notorious for undercharging for all their time and hard work. We’re talking single-digit percentages of what industry professionals charge for roughly equivalent quality.
And then when one encounters a financial emergency, they desperately scramble to take on a lot more work just to pay for whatever life event happened. If the artist hadn’t been leaving so much money on the table with their commissioners, they probably wouldn’t need to do emergency commissions in the first place–let alone endure the mental toll of delivering on them.
It’s tragic.
If you’re not sure how much you should charge at all, I recommend the following algorithm:
Calculate your floor.
Increase your rates.
Are you able to consistently fill your commission slots?
First, benchmark how long it takes you to complete a typical item on your price list. For example, a sketch of one character might take N hours to complete on average (with variance granted for complex character details).
Next, decide on a fair hourly rate for your work as a professional.
Don’t undersell yourself! For example, your hourly rate should never be less than $24 per hour (in 2020 dollars), in the United States. This number is based on what the federal minimum wage should be, if it was pinned to productivity. If that seems too high for you, don’t go below $15.
Whatever number you landed on, immediately double it. Roughly half of your income will be eaten by taxes (income taxes–including state income taxes if applicable–plus payroll taxes since you’re self-employed as an artist), unless your tax accountant tells you otherwise.
Now that you have a number in mind, you’re going to want to go through the rest of your price list and make a mental note of how many hours each item will take you to complete.
For example: If a complete illustration of one character with a detailed background takes you 8 hours, and each additional character takes an additional 2 hours, you can setup your pricing as follows:
where is the number of additional characters beyond the first one, is your minimum hourly rate, and is the price of a commission.
If you decided , then your price list entry for this type of commission might look like this:
$400 + $100 per additional character
You should do this for every item on your commission price list.
Increase Your Rates
Once you have a price list figured out, you will want to occasionally increase your prices.
Generally: If you’re utilizing 100% of your allocated time for art, it’s time to increase your rates. This means you have sufficient demand to justify a price increase.
If you’ve allocated 40 hours of your time per week for commission work, and you’re consistently allocating all 40 of those hours, it’s time to increase your rates.
(This logic also applies to commission “slots”, but not all slots are equal. Use your best judgment here.)
How to Increase Your Prices
There are different schools of thought on pricing strategies. As a computer programmer, my generally recommended strategy is similar to a git bisect:
Double your prices.
Are you able to fill at least 50% of your commission time allocation at the new prices? (Let’s call your old price N, and your new price 2N.)
No: Go exactly halfway between the old prices and the new prices (1.5N).
Yes: Are you able to consistently fill 100%?
Yes: Go back to step 1. You haven’t doubled them enough.
No: You may have found your prices, but don’t bail out just yet. You know that 2N yields between 50% and 100% utilization. If you dropped down to 1.5N, you’d very likely see 100% utilization, so your ideal rate is probably somewhere between 1.5N and 2N.
So try 1.75N.
If you’re below 50%, you need to go down (1.625N). If you hit 100%, you know you need to go up (1.875N).
Recursively iterate this process, increasing half as much as the previous step.
Keep this up until the difference between this step and the next step is smaller than some threshold (e.g. $5) or you’re at a comfortable utilization between 50% and 99%.
Working Through An Example
Let’s say you were charging $50 for sketches, $150 for lined art, and $300 for full colored illustrations, and your commission queue is always filled.
First, double your prices (sketches: $50 -> $100, line art: $150 -> $300, full colored illustrations: $300 -> $600).
If your next batch of commissions gets filled to 100%: double them again (sketches are $200, line art is $600, full illustrations are $1200). Keep doing this until you’re not at 100% utilization.
If, after you’ve finished a cycle of doubling, your next batch of commissions is between 50% and 100% utilization, sit tight at your current rate. Demand for your art will increase as you grow your audience, and you’ll find yourself needing to start the process over with again.
However, if you’re at below 50% utilization, it’s time to step halfway between the old and the new. If going from the initial ($50, $150, $300) to the new ($100, $300, $600) dropped demand to below 50%, your new prices would be ($75, $225, $450). If you’re still below 50%, you can keep decreasing it further.
(Feel free to round these numbers, but err on rounding them up.)
If you started at 100% utilization, this process will end up at some price greater than your starting point.
Note:
Every time I’ve said “your prices” above, what I’m talking about are your standard rates, not what you’re offering on a particular day.
You should absolutely feel entitled to offer discounts, sales, and special deals whenever it suits you.
Deeper Analysis
Computer science majors will recognize this strategy as approximately a binary search algorithm.
A true binary search would zero in on your 100% utilization prices if you were capable of going above 100% utilization, but I wrote this with the assumption that 100% utilization is a market signal that you need to raise your rates. This is the guideline we’re using, because I’m assuming you cannot go above 100%. (That’s how you get burn-out!)
If you replace 100% utilization in the “true” binary search algorithm with another target percentage (say: 75%, and you bail out when you’re within 2.5% of this value), you will zero in on prices that meet your threshold.
The reason we’re increasing/decreasing by powers of 2 with each recursive iteration is that it’s the most efficient algorithm available.
A more naive approach would be to, instead of going from 2N down to 1.5N, decreasing by 0.1N until you hit your goal.
If you’re going from $100 and trying to hit a 90% utilization, and the magic number that hits that number is $147, the comparative strategies might look like this:
$100 -> $200, 60%
$200 -> $150, 88%
$150 -> $125, 100%
$125 -> $137, 100%
$137 -> $144, 100%
$144 -> $147, 90%
$100 -> $200, 60%
$200 -> $190, 65%
$190 -> $180, 70%
$180 -> $170, 76%
$170 -> $160, 82%
$160 -> $150, 88%
$150 -> $140, 94% backtrack, smaller increments
$140 -> $149, 88%
$149 -> $148, 89%
$148 -> $147, 90%
The efficiency here is important: More price changes in a short time interval can make customers nervous.
In the example above, if 88% was acceptable, you could have stopped at $150. That would have been two total operations for the binary search and six for the gradual step-down approach.
In all but the most contrived scenarios, you want to use a binary search strategy.
Consider Hourly Commission Rates
Price lists have a tendency to get complicated, especially when complex character details (your fursona is a wolf, but with wings!) enter the mix.
One alternative to this is, after applying the price algorithm above, simply express your prices in terms of how much time a piece of art typically takes and advertise your standard rate.
Then your commissioners will know they’re hiring you for e.g. $50/hour for a project that typically takes N hours.
Improving the Furry Art Commission Experience
Guidelines for Artists
Communicate with your commissioners. If you’re not using something like Trello to track your projects, you should send them updates more than you’d normally feel comfortable. The more complex the work, the more updates you should send.
Dates Rule Everything Around Me. We understand that you have multiple projects–often running in parallel–that need to be completed to keep your clients happy. We know we’re not the only iron in your fire. Give estimate completion dates as soon as you can. If you can’t give a completion date, give an estimated date for a date. (I’m serious. This will virtually eliminate commissioner anxiety.)
Be transparent. If you need more time to get a piece done, tell your commissioners as soon as you can. Shit happens. We all get sick. We all have unproductive days/weeks. Anyone who doesn’t understand this is someone you probably want to decline accepting work from in the future.
Guidelines for Commissioners
Be polite. It’s difficult to understate how important basic manners are, even moreso when nobody seems to practice them.
Don’t bitch about prices. If you can’t afford their rates, you have three choices: Save up money for this luxury expense, move onto another artist, or learn to make it yourself.
n.b. This includes telling artists they should charge more! If you’re going to do that, your words must be accompanied by a generous tip. If they aren’t, you’re an asshole.
Updates are your opportunity to request changes. If you just say, “It’s coming along great, thanks for the update!” then you’re agreeing with the current direction of their work.
If the artist forgot an important detail (e.g. a marking on your fursona), the sooner you tell them, the sooner they can correct it. You aren’t being rude by informing them (unless you word it rudely; use good judgment!).
Credit your artists. Always. Link to their account too, if reasonably practical.
A lot of an artists’ income is the consequence of their previous commissioners showcasing their work. Word of mouth is the best form of advertising most can afford.
If you credit your artists, you’ll be helping them stay afloat until you decide to commission them again in the future.
I’ve received a bit of feedback since I first published this article from various sources (Reddit, forum posts in other languages that I can only hope Google Translate got right, etc.) and I thought I’d address some of your questions and concerns here.
“It takes me forever to get art done. Should I bill for my egregiously slow time?”
There are three reasons I’m aware of that could lead an artist to have a glacial work pace.
They have insufficient art practice
Their techniques and strategies aren’t time-efficient
They live with some sort of disability
For the first two reasons, the solution is simply to practice more, try different techniques, and learn from other artists so you can get your work pace fast enough to earn a living from art. It’s okay if you’re still somewhat slower than your peers, but until you’re able to consistently produce art at a reasonable rate, you’re probably not ready to do art professionally (and that’s okay, not everyone has to be).
For the last one, I don’t have any useful advice. I don’t know your disability and am unqualified to advise you on what to do to overcome the challenges you face as an artist because of it. The advice on this page is intentionally very generalized and I’m sorry it won’t help you.
“My clientele only make poverty wages. How can I raise my rates without betraying them?”
I mean this in the gentlest way possible: If you’re in this situation, you do not have clients, you have friends. Friends are an incredibly good thing to have. Humanity overall severely underestimates the importance of good friendships, especially in America.
But if you’re trying to earn your living through art, you have to distinguish between the two. Clients are people who–whether through income or saving up–can afford to pay you a livable wage for your time as an artist.
That isn’t to say that you can’t continue to give your friends a discount, or even free art. They’re your friends, it’s your time. Do what you will. I mentioned this above. But if you’re doing real work, you should be getting paid a real livable wage.
Your friends might even be able to help you find clients that are able and willing to pay for your time. Don’t write them off or treat them as second-class.
“This advice doesn’t apply to me because my customer base is small, or nonexistent. What now?”
There are a lot of things you can do to change this fact, but I’m not qualified to speak competently to them. (If I knew the secret to a larger social media following, don’t you think I’d have used it for myself?)
Ask artists in your community for help and advice. Some might even help increase your follower counts so you can acquire more business.
“How do I find furries with sufficient disposable income to pay a livable wage?”
The truer but non-helpful answer is, “You don’t, they’ll find you.”
A lot of furries that work in tech fit the bill, but not all of them. Additionally, some well-off furries are righteous assholes and you really don’t want to deal with their bullshit.
The best advice I can offer here is:
Be active on social media.
Be kind to people on social media.
Don’t be afraid of self-promotion on your own feed.
Everything else boils down to patience and luck.
“I’m not an American, so what should I do differently?”
There are two schools of thought here.
On one paw, you can localize your prices to the cost of living for your area. This will ensure your needs are met and you can comfortably continue to work as an artist in relative comfort.
On the other paw, you could recognize that the Internet is an international marketplace and you are, at least in part, competing globally for clients. Many clients will come from wealthy countries and have the income or savings to facilitate large commissions, and therefore you can earn more money for the same work.
Use which ever you like better as your guiding light. I’m not a dictator, and even if I was, I have no mechanism to force you either way.
“What if I don’t want to make a livable wage as a furry artist, and just want to make art for other furries as a hobby?”
Why’d you click the link to this article?
“What would an increased bill rate look like for an artist that followed this advice?”
See this post for a detailed breakdown of furry fandom art spending, accompanied by an analysis based on an arbitrary rate at $50/hour and utilization at 30 hours per week. (Spoiler: It ends up at about $80,000/year.)
“This pricing advice isn’t specific to furry artists, it’s general pricing advice for freelancers in any industry!”
It’s true, I didn’t invent these tactics or pull them out of a magic hat. If you’re trying to make it in the world as a professional, price your work like a professional.
From what I can gather: Roughly half of the people that read this blog post picked up on this nuance immediately. Y’all are pretty sharp.
Original art by Khia, poorly edited by myself.
Art by Swizz.
is the number of additional characters beyond the first one,
is your minimum hourly rate, and
is the price of a commission.
, then your price list entry for this type of commission might look like this:
Art by Khia.
Art by Khia.
Ding ding ding!
