enhance: Allow switching to a more expensive territory #1919
Conversation
Soxasora
force-pushed
the
enable_territory_switching
branch
3 times, most recently
from
d148b80 to
88a9f5c
Compare
Soxasora
force-pushed
the
enable_territory_switching
branch
from
88a9f5c to
fa7725b
Compare
There was a problem hiding this comment.
The main issue with this is that it neglects the spam multiplier.
This is hard to do because without recording the spam multiplier, all we're able to do is deduce that there was a spam multiplier.
This creates a small spam loophole. For example:
00:00: Post once in ~bitcoin for base cost of 100 sats
01:00: Post something else in ~bitdevs for base cost of 10 sats * 10 = 100 sats
01:01: Edit post to be in ~bitcoin for 90 sats more, effectively saving 810 sats
As part of my paid action refactor plans, I intend to create a Receipt table which will have the line items in it and this kind of thing should be easier to do. Not sure what to do in the meantime.
|
Oh, you're right! I didn't foresee this loophole... and I think we can adapt the spam multiplier from itemCreate to itemUpdate for it (just for sub switch1), I'm going to take a look. Thanks a lot! Footnotes
|
| const [oldSub, newSub] = await Promise.all([ | ||
| models.sub.findUnique({ where: { name: oldSubName }, select: { baseCost: true } }), | ||
| models.sub.findUnique({ where: { name: newSubName }, select: { baseCost: true } }) | ||
| ]) | ||
|
|
||
| const subDifferenceCost = Math.max(0, (newSub?.baseCost ?? 0) - (oldSub?.baseCost ?? 0)) | ||
| if (subDifferenceCost === 0) return 0 | ||
|
|
||
| // calculate spam cost exclusively for sub switch | ||
| const [{ totalCost }] = await models.$queryRaw` | ||
| SELECT ${satsToMsats(subDifferenceCost)}::INTEGER | ||
| * POWER(10, item_spam(NULL, ${me?.id ?? USER_ID.anon}::INTEGER, | ||
| ${me?.id ? ITEM_SPAM_INTERVAL : ANON_ITEM_SPAM_INTERVAL}::INTERVAL)) | ||
| * ${me ? 1 : 100}::INTEGER as "totalCost"` | ||
|
|
||
| return totalCost |
There was a problem hiding this comment.
It's mostly the same as itemCreate's spam multiplier, another change is parallel sub base cost querying.
I did some tests, following also the loophole scenario you mentioned and it's smooth!
Description
Completes #1918
Allows switching to a more expensive territories during post editing by paying just the difference between the old territory post cost and the new one.
A downgrade will have 0 cost.
Screenshots
I'm moving from B2B which costs 1 sat to everythinghere that costs 2780 sats.
The edit cost will be 2779 then
Additional Context
Perpetual Edits will allow this change to be done indefinitely instead of during the first 10 minutes time window. We could allow sub-changing only in that time window to prevent eventual abuse or sub-hopping (idk if bad)
Checklist
Are your changes backwards compatible? Please answer below:
Yes
On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:
7, tested before on perpetual edits, tested on multiple territories, downgrade has 0 cost
For frontend changes: Tested on mobile, light and dark mode? Please answer below:
n/a
Did you introduce any new environment variables? If so, call them out explicitly here:
No