App/Web Dev Services by 1ielvis (@2581/@eltoritoelvis)

Use the tag 1ielvis and/or reach out on Club Relay/Twetch/Twitter to get my attention if you want to work together.

Proof of Work

• Gopnikz.biz
  • Built this for the Gopnikz team. Features include custom ranks/filters, viewing NFT's in your wallet, purchasing NFT's on site & token gated content.
• Satoshi Price Index
  • An informational site that shows the current price of the US dollar, the top 15 items from the US Bureau of Labor Statistics and Run tokens in satoshi pricing. Updated monthly with new CPI data.
• Sonic Boost
  • Audio Bitcoin NFTs ranked by proof of work. A place to play and boost your favorite audio NFTs.
• La Fonda de El Ceboruco Club
  • This is a recipe website that token-gates recipes/videos. I built this project for my mom. She's the cook and these are her recipes. You can Boost your favorite recipes!
• Powco.show
  • Same concept as above but built specifically for the Proof of Work Company. Token holders can view the recorded daily meetings. The required amount to watch the video decreases by 100 tokens each day down to a 100 minimum.
• Jiujitsio
  • I built an app that lets you create mind maps of jiu-jitsu techniques using D3.js for the graphs. My favorite part of this was that if two techniques shared a common position (node) you could visualize both and see where they share a position.

Dev Issue Smart Contract: Plan

by 1OwenKellogg

Given that I have written several times about the Powco dev contract I would like to write some more on it and then publish this writing. That way I have an outlet for these writings and may establish a better practice of typing and publishing them. So far I have described three types of scripts that I would like to use to develop Powco.dev. Each of these scripts may be seen as a smart contract that stores state across transactions and may be interacted with. The first most basic contract is the Issue Contract, which used to be a simple json object embedded in an op_return output. The issue in the new paradigm shall have an owner who may transfer ownership of the issue, making it into an NFT enforced by miners. My first implementation of the token woefully failed at providing such capability, in fact it does not even attempt to provide ownership capability. Rather than implementing the basic non-fungible token abilities myself this token shall inherit from the example “ERC 720” implementation provided by scrypt. That way any wallet in the future that understands ERC721 non-fungible tokens will be able to recognise, receive, store, and transfer ownership of the GitHub Powco dev issue NFTs.

On top of the base ERC721 more methods will be added by extending or inheriting from the ERC721 base class which itself inherits from the SmartContract base class. The first implementation added some metadata about the issue as state properties but did not allow for stateful editing of the title as the description which would generally be achievable for a GitHub-like user experience. The one thing that ought to stay static is the organization and repo since ninety nine percent of the time that will never change and if it does it might make sense to simply deploy a new transaction. Github does not allow that to be changed. When a Powco Dev Issue contract instance is first deployed it should be registered with Powco.dev via a peer to peer api call. Within that shall be a typescript function that takes raw transaction hex strings (or a Buffer) as input and detects one or more instances of the Powco dev issue contract if they exist. The function should be able to determine whether this instance is the originator or origin transaction for the stateful contract or whether the current locked output is a subsequent transaction containing updated state from a previous deployment of the contract instance. Once a Powco Dev Issue has been discovered by the parser function the system should be able to determine the entire state change history of that contract including crawling back to the origin transaction as well as crawling forward to the current state of the contract until it finds an unspent transaction locked output.

On a more abstract higher platform level there needs to be a more generic service for stateful contracts. Ideally this service can detect any time an scrypt contract using the transaction pre-image to enforce statefulness, if such a feat is even possible. Perhaps the service will need additional information provided to it such as the ABI of the contract instance. More research is required however the design can progress at present nonetheless. Similar to the RunDB which syncs the current state of Run jigs in a layer two index (layer two meaning the state is not enforced by miners), this index will track the current state of all known stateful smart contracts. It would be nice to build a database of known deployed contract ABIs, or have a way to discover the ABI given a particular script.

Ultimately the Dev Issue Contract or perhaps simply the Issue Contract will simply mirror GitHub issues and will not at this time contain bounties, though it will contain satoshi and as an added bonus will be transferrable from one owner to another. When someone wants to create a new issue they should be able to do so directly from Powco.dev and that issue should be added to their “my issues” section where they can see all of the issues they have created as well as transfer ownership of an issue, close or re-open the issue, update the title and description of the issue, and see a history of transactions related to the issue. The API shall return this list of transaction history for an issue (ie state changes), and will track ownership history of issue NFTs and report an API giving the owner of a current issue, as well as a list of issues owned by a given user. It might be cool or useful to allow for multiple owners or admins. Also it might be most desirable to allow for a global override for the issue but then again maybe it should be all done by the owner, and if they make a mistake by transferring the item to an invalid account then the issue may never be marked as complete. If a site admit wants they may display issues owned exclusively by certain contributors, or perhaps maintain a separate data structure for some kind of blacklist to remove invalid issues from being displayed.

Altering the genitals of another person without their consent is immoral. When done as an infant, removing the tip of the newborn's penis involves putting his arms and legs in restraints, and cutting is performed without drugs, resulting in pain so excruciating, the child passes out. Some baby boys die every year in the US from complications resulting from this medically unnecessary procedure.

The injury endured by the infant releases a flood of cortisol (stress hormone) altering the child's brain development and psychology for life. While some say it is only a small bit of skin, the area removed accounts for 50-70% of the nerves in the penis, depriving him as an adult of 50-70% of the sexual stimulation he would otherwise have -- for life.

This decision is made on his behalf without consideration for his immediate pain, long-term psychological implications, future sexual performance and its impact on his life-long relationship with a partner, or even the risk of his death -- and it is done to him not by enemies, but by the people who claim to love him most. His reproductive organs are permanently damaged without anesthesia in his first hours of life outside the womb by the very people who are responsible for keeping him safe from harm and who claim to want the best for him to give him every opportunity.

Imagine the effect it will have on your relationship with him as his parent when he realizes what you have done to him intentionally, at your direction, and without apology. Can you imagine the shame and regret you will feel having that conversation with your adult son and having nothing to say for yourself?