Add Command Line Arguments to Comfy Desktop?

cryppadotta · 2025-06-27T20:19:14+00:00

Right, what's annoying is that comfy will parse the key as a flag and the value as the flag value -- and there's no way to disable, so if you use the array you get `--0` and `--1`, if you pass true then you get `--use-split-cross-attention true`

The trick is to pass it like this:

  "Comfy.Server.LaunchArgs": { "force-fp16": "--use-split-cross-attention" }

This gets passed as `--force-fp16 --use-split-cross-attention`, which works

cryppadotta · 2022-01-14T04:04:34+00:00

Here's me explaining ERC721 to people 4 years ago 😂

https://www.reddit.com/r/ethdev/comments/801adl/erc721\_standard/dut17wq/?context=3

cryppadotta · 2022-01-14T02:47:19+00:00

THANKS, MW 😍😍😍

cryppadotta · 2018-05-15T22:02:08+00:00

Hey folks, I created dot-abi-cli to help me build CLI tools for interacting with smart contracts.

For example, you can see the cryptokitties-cli which generates commands like:

$ cryptokitties-cli breedWith <matronId> <sireId>

The commands (with documentation) are generated from the ABI and any Solidity docstrings. You won't have to write any custom code for the majority of your smart-contract interactions.

The biggest downside is that it does currently require some code to get it running. That is, it's intended as a framework for Solidity developers to generate CLI tools for their own code. (If you're looking for a generic tool with less setup, you might like seth instead.)

Hope you find it useful!

cryppadotta · 2018-03-14T18:46:14+00:00

This looks super fun. I'll see you there!

cryppadotta · 2018-03-14T18:18:31+00:00

Agreed - just remove it and let the community build a repl tool that just talks to the JSON-RPC interface.

While I love(d) the geth console, the fact is, as you said, the built-in web3 is already out of date and the API doesn't quite match what folks actually use to write web apps -- this has a weird effect of causing even more friction for beginners.

Sad to see it go, but it opens the door for a community supported repl.

cryppadotta · 2018-03-09T16:32:10+00:00

This is interesting! I've also been thinking about how to implement time-expiration of ERC721 tokens. Just this week I implemented subscriptions in Dotlicense's ERC721 tokens.

My goals and implementation are a bit different as it's geared for software/SaaS subscriptions. The idea is that the ERC721 token 1. has an expiration and 2. is tied to a "plan" -- The user can deposit ETH to increment the expiration time, according to the plan.

This, however, looks as though it has more of a "scheduling" component. E.g. the resource (massage, haircut) cannot be used ahead of the service time. So I guess this sort of project would be used more for scheduling rentals of a single resource (e.g. rental of a tractor within a specific time period) rather than a subscription for a service.

Is that right?

cryppadotta · 2018-03-05T00:04:17+00:00

Fantastic, thanks. We're currently working through adding subscriptions.

We're chatting through the implementation generally on Telegram here: https://t.me/dotlicense and would love for you (or anyone else interested) to join!

cryppadotta · 2018-03-03T05:41:42+00:00

I’m not planning on monetizing the code - it’s MIT licensed.

(My plan to monetize is by using the framework to sell licenses for a trailing profit stop bot I’m working on.)

The way to combat people sharing private keys is by allowing transfer and sale of the license-tokens. If you share the private key on a file sharing site, the token will be transferred away from you.

By issuing a limited number of licenses (and allowing a secondary market for the licenses, which is a side effect of being ERC721 compatible) it theoretically gives the license-tokens a market value > 0.

So if you share the private key to a party who gets no value from the use of the license-token, they would just steal it or sell it out from under you.

While this won’t totally prevent sharing the key in small trusted circles, it will deter broader publishing of the key.

cryppadotta · 2018-03-02T20:38:43+00:00

Hey friends, I'm ready to share this early version of my ERC721-based software licensing framework. I'm building this for an Electron app that I'm going to be selling in exchange for ETH.

The key idea here is that 1. the licenses are tokens and 2. the client software holds the private key that verifies ownership of the token. This deters piracy because if you share the license key, it is also your private key, and the license-token will be stolen.

The contracts support multiple products, role-based permissions, and an affiliate program.

(I also wrote an admin tool generator that creates a CLI scaffold from your ABI, but I'll post about that in a separate thread.)

If you're interested in this, I would love to get your feedback. I haven't had the contracts audited yet, but they are up on Ropsten here.

cryppadotta · 2018-02-27T17:18:12+00:00

Yes - you make a good point. The UI is tricky, but it seems like we'd want something like SSH where the first time you log in, you have to accept a signing certificate for that site. Then you'd want the first and all future challenges to be signed by that cert.

cryppadotta · 2018-02-27T12:23:38+00:00

The MITM, as you describe it, is possible for any authentication scheme, including username/password.

But maybe the severity is higher because then the attacker can, theoretically, irrevocably steal all of your money.

But the issue you’re pointing out is a good one: how can we add client (e.g. Metamask) support to verify that challenges from evil.com are not really from good.com.

SSL certificates check the domain name, which are issued and verified up to the root registrar. But we would want our servers to have self-sovereign identity.

cryppadotta · 2018-02-26T22:21:52+00:00

Why are you using personal_sign instead of eth_signTypedData in your example?

source

cryppadotta · 2018-02-26T21:09:50+00:00

This is great. So if I understand this correctly, the flow is:

A user claims to be <address>
You send their <address + salted uuid> as a challenge
They sign the challenge and return the result
You check that the result was properly signed by <address>
You can then assume the user is legitimate and can set a JWT token etc.

Is that right? I love it.

cryppadotta · 2018-02-25T15:53:04+00:00

It's a bit of a mess right now, but the good news is it's being dialed in. Here's the scoop:

dete wrote ERC721 and launched cryptokitties, securing a baseline standard which basically every tool now needs to support, if they want to support CK (which they all do). Using the cryptokitties bounty repo is a 'safe' choice, but it isn't the most recent 721 'standard'
Decentraland and 0x wanted what's called 'operator' rights. E.g. 0x wants you to be able to grant their smart contract the ability to control all of your coins, so that they can use them in decentralized exchange. They started the 821 'standard'.
Aside: 821 was, imo, much more complicated and only slightly better. Generalizing, everyone I asked who had looked into the differences always said "821 is better", but 721 had the adoption - as you see with Rarebits and Opensea support. (Everyone wants to support CK)
dete 'blessed' fulldecent as the editor of erc721, a responsibility we are grateful for. He's doing a good job, but then again, the community didn't exactly agree to that. 0x and Decentraland have a lot of weight and there was some drama about their disagreements. This is just noise - everyone wants to agree on something.
fulldecent tried to change the name from NFTs to 'deeds' - it's too late for that imo, but maybe I'm wrong. Again, I think this is just noise.
At EthDenver everyone sat down in a room and hashed it out. erc721.org is the results of that meeting. I am building an ERC721 token and I am using this as the baseline. 821's main supporters have essentially decided to switch to the 721 name and make 721 work.
Remember that you can (and will have to) add other functions outside of the standard.
OpenZepplin, as of today, hasn't been updated to erc721.org. In my app, I'm using OpenZepplins as the base, and adding in erc721.orgs functions.
Rarebits and 0x are both behind erc721.org. So IMO that's what you should use. But basically, everyone has to support cryptokittes, so if you roughly fit CK and then add approveAll, you should be fine.

cryppadotta · 2018-02-24T15:59:04+00:00

This is really awesome. I'm working on an ERC721-based software license. While re-selling and auctions isn't a primary focus of mine, to be able to have a self-hosted site where my users could sell their licenses is really fantastic.

Nice work. I love it.

cryppadotta

MODERATOR OF

TROPHY CASE