No need to display the rate per unit of time. Rather a small widget like a fixed bar that gets depleted as time goes on could convey a similar idea.
Well it's not the same really, because you don't show the payment rate, but rather how far into its lifetime a job post is. This I'd argue is even more relevant information than the rate. Plus if you access the section a different times a day o after some days you'll get an idea of the payment rate anyways.
I don't see any technical problem with implementing this. For instance bitcoin payroll companies can do this already even as a proof of concept.
The only problem would be inbound liquidity so every once in a while, receive would go from LN -> onchain to cold storage for long-term savings.
sats/min might be a scary proposition to the tradfi accounting dept. I can already envision the squeals and pushback. But somethings gotta jolt them out of 1971 style ledgers. :)
Those jobs aren't paying their employees in sats/min. They're paying SN to list their job in sats/min. 🤦♂️
Thanks! I've added a correction.
Added this post to the existing issue #194 in SN's Github repo.
Clarify that "n sats per min" in jobs board is NOT the wage / compensation being offered for the job https://github.com/stackernews/stacker.news/issues/149
I know! You were the first to point to the confusion. I haven't come up with a decent way to rephrase it so it isn't
I'd consider one or some of the following:
No need to display the rate per unit of time. Rather a small widget like a fixed bar that gets depleted as time goes on could convey a similar idea.
Well it's not the same really, because you don't show the payment rate, but rather how far into its lifetime a job post is. This I'd argue is even more relevant information than the rate. Plus if you access the section a different times a day o after some days you'll get an idea of the payment rate anyways.
I think the rate is more important than the tab.
The rate is a signal to the market about how serious they are to hire for the role.
The tab can be topped up willy nilly. Or probably reduced also.
I don't see any technical problem with implementing this. For instance bitcoin payroll companies can do this already even as a proof of concept. The only problem would be inbound liquidity so every once in a while, receive would go from LN -> onchain to cold storage for long-term savings.
sats/min might be a scary proposition to the tradfi accounting dept. I can already envision the squeals and pushback. But somethings gotta jolt them out of 1971 style ledgers. :)