> they used whatsapp for coordination so I didn't join
How much personal opportunity cost is acceptable before it becomes worth using a platform you don't like...?
Remember that even if it your life's sole goal to eliminate the use of that platform worldwide, you will probably achieve more if you take every opportunity possible, including those gatekept by the platform you don't like...
Then you wrote your original message in a very odd way, implying it was because of the WhatsApp use that you did not join. Not harping on you, just an FYI in case you're learning the language or would like to increase communication skills.
Yeah, textual inversion is amazing paired with SD.
I recently trained it on NFTs to generate variants of bored ape and punk style art.
The only problem right now is the variants are not consistent and it's hard to tell stable diffusion to make only slight variant changes with some mask and editing.
You can mask out the top head of the NFT punk and stablediffusion can generate different heads but that's fairly limited in the end result.
I think a cloud service which can automate the training and store textual inversion models would be a really cool startup. Ping me if you want to build this together.
I've been experimenting with it to spit out commercial style illustrations and stock photos. It's a lot of manual work with Google collab and frustrating to try.
Is there any post which goes into evolution of prisma from initial days of exposing graphql API directly to using it as wire protocol in the query engine?
And now the likely removal of graphql as wire protocol. What are the key reasons to remove the use of graphql query language?
> Is there any post which goes into evolution of prisma from initial days of exposing graphql API directly to using it as wire protocol in the query engine?
To be honest, I think the most comprehensive resource for this is a Twitter thread [1] that I posted from my personal account that explains the different turns we took in the product direction :D
Otherwise, there's yhr blog post "How Prisma & GraphQL fit together" [2] that also touches on the same topics but might be a bit dated since it was published before we released the Prisma ORM for production use.
> And now the likely removal of graphql as wire protocol. What are the key reasons to remove the use of graphql query language?
The short answer is that it would allow us to make us more optimizations for the bridge between JS- and Rust-land in Prisma Client. However, this is not an urgent issue for us at the moment so very likely won't become a priority in the near/mid-term future.
I like to use email aliases for privacy and security which works better with domain provided by common operators such as duckduckgo, mozilla relay, apple icloud, etc. If you use a custom domain, then it is easy to link all your accounts through data brokers and spam you because all addresses get redirected to your inbox.
You can whitelist only specific localpart patterns, which solves the spam problem. And while it’s in theory possible to link all addresses to your identity, doing so would require knowing that only one person is using the email domain.
> it is entirely up to you to either reveal your transactions to parties of your choice or keep them private forever. Keep in mind, that none of it is possible without the Tornado.cash Note and it is your responsibility to keep a record of it if you want to show the origin of funds later.
That's just a digital timestamp service, only a small part of what I'm talking about.
Mind you, I don't claim any novelty in the process I sketched above - just professing the need to have it implemented before we can treat crypto-assets as anything other than a money laundry tool.
What you have proposed is technically infeasible to implement if you want to preserve properties of blockchain. It would be no different than a bank because KYC will add inherent centralization and fragmentation in the entire system.
So we need a compromise here because either way you cannot retroactively enforce KYC approved wallet to participate on-chain. If you do, it will be optional in that case the solution implemented by tornado is decent and does not require giving data to brokers who often sell it without permission.
Government can directly subpoena data from individuals when investigating them.
Any crypto to fiat ramp is already KYCed and businesses dealing with payments require KYC beyond a certain value transaction so in practice, the impact of KYC at on-boarding will be negligible. Not to mention, KYC can be easily faked by actors with significant stake in a globalised system.
Furthermore, the data does not support that money laundering is a bigger problem as percentage of transactions in crypto than traditional finance. The AML laws have been largely ineffective in practice in traditional finance with huge cost of compliance and degradation in experience for consumers & businesses.
So we need to think of a better solution to discourage money laundering than mass surveillance.
KYC is by definition a form of centralization - the government endows a well known private entity with the authority to run financial transactions on behalf of individuals, subject to certain constraints and information gathering. Since any form of practical KYC involves centralization, my proposal is to have an open system where brokers can join and compete amongst themselves, and where hopefully you might find one that does not sell your data.
There is no logical compromise between a KYC value transfer system and a non-KYC system, you either have auditable customer identity or you don't, in which case all is lost due to the Sybil attack: the money launderer can create a limitless number of pseudonymous identities (for example in Bitcoin, wallets) and transfer value both om chain, and off chain, by selling those funded identities (see for example the method used by Chipmixer, where the actual value transfer happens after the "clean" coins have been injected into the blockchain, sometimes months after).
That fiat converters are obliged to follow KYC is irrelevant to the issue being discussed here: blockchains as money laundering machines. The police will never ask a successful criminal for their tornado proof because police will most often be unable to follow the proceeds of crime through the pseudonymous value mixer that is the blockchain.
> the data does not support that money laundering is a bigger problem as percentage of transactions in crypto than traditional finance. The AML laws have been largely ineffective in practice in traditional finance
Anti-money laundry coverage is spotty in the traditional financial system. Where it is employed, it's very effective in exposing criminals, curbing their profits, thus motivation for crime, or pushing them into risky and noisy beheaviours (ex. truckloads of cash). Current blockchains are by design unable to comply with the most basic AML requirements and it's sheer lunacy to brush that problem aside or claim that crypt is in way comparable to physical cash; it's crack cocaine vs weed.
Almost all banks are required to comply with tracking and sharing tax information due to OECD agreement at country level for tax reporting standardization.
It's the default regardless of the country unless you are sanctioned.
It's a factor but only a single one among multiple others.
It is not prohibited for an individual to maintain a foreign bank account in India but capital controls (FEMA) applies and banks providing services to Indian residents might need to comply with regulatory framework.
It's the same in most countries. The regulatory burden may be different but banking presence is required in the country if you are serving domestic market at scale.
Indian residents can open HSBC expat account domiciled on the jersey island as an example.
At least in India, banks are required to pay you every day for delays to resolve major issues beyond what is considered reasonable. OP's case would likely fall under it.
It's part of RBI (Reserve Bank Of India) guidelines. The scope is expanding every few years to cover every situation.
