The Fluence DAO has decided to distribute 5000 FLT to each GitHub user that has contributed to “web3 repositories” according to an announcement from 2024-02-27 on their blog (see also their FAQs). For their definition of a “web3 repository”, they are using the “Crypto Ecosystems taxonomy” by “Electric Capital”. It turns out that this taxonomy lists multiple forks of Nixpkgs. It is unclear which commit range of Nixpkgs exactly is relevant, but everyone with commits in Nixpkgs “in 2023” should be eligible.
I created a Hedgedoc. If you have factual information to contribute, or want to install a notice that you are accepting FLT donations, please just edit that right away. I am happy to lock the Hedgedoc as soon as there’s donation information added to it.
Note that I am in no way affiliated with Fluence and this is not an endorsement. Tagging people that appeared to be active in the Starknet case: @edef@qyliss@RaitoBezarius
I’ll happily lock the Hedgedoc as soon as someone actually enters donation info that should be protected. Anyone mistrusting me about the changing the Hedgedoc can of course disregard my suggestion and distribute their information however they like.
In the meantime there have been useful edits by others, and noone has indicated that they actually want to handle donations, so I’ll keep it freely editable…
Fluence filtered public keys only accepting exactly ssh-ed25519 or ssh-rsa. The keys at https://github.com/Kranzes.keys are sk-ssh-ed25519@openssh.com which is not supported.
For example, if you go and print all public key formats of all public keys that were rewarded, you again end up with exactly the two above:
I don’t believe that this is a realistic demand the community to go through the process to redeem this, their value is unknown, the efforts are high and the risks (on the path to make them fiat) is high, compared to StarkWare.
Therefore, I do not support this initiative, I recommend everyone to do their due diligence before rushing out, e.g. risks for your GitHub account, risks for your bank details, etc. and remember that this sort of thing can be quite stressful, it is not a shame to skip it.
my keys seem to have the required ssh-ed25519 format, and i’ve got steady commits since 2022-06-01, but do not appear to be on the list. i’m gonna guess those nixpkgs repos were forked off more than a couple years ago.
I also can’t figure out what’s wrong in your case. If you’re really interested, you might want to ask on their on their Telegram or their Discord but don’t expect a timely answer. There’s lots of people asking lots of questions about the rewards.
Fair. To me it was important to inform the community and to have this thread for discussion, including words of warning like yours, which are very much valued, and the Hedgedoc for high-quality information. So that everyone can make an informed decision on their own.
Like with Starknet, the token is exchanged/swapped already and there is price information on sites like Coingecko. You can trade this token for 1 EUR today. What’s different from Starknet, is the lockup period of two months that adds uncertainty. However this in itself is just a tiny risk: If you claim today and the price goes to zero within the next two months, the money you have lost is transaction fees which are below 10 EUR.
On the surface it’s quite similar to Starknet. You also have to set up a wallet (this time for Ethereum, not for Starknet) and instead of logging in with OAuth you decrypt a challenge and sign it locally. What’s different (and I guess that this is what you meant) is that you need to call a smart contract to claim the tokens, which implies that you have some ETH to cover transaction fees.
People that don’t want to do this may consider donating, which they can do by solving the challenge and sending their proof to the donee.
I’d be curious to know why you say that the risks to convert to fiat money is higher than with Starknet. I don’t see any reason myself. Both are super risky crypto assets, of course.
Again, I’d like to highlight that I am not trying to blindly promote Fluence (in fact I am quite skeptical myself and consider every EUR invested/spent on this thing to be gone forever), but that my questions are genuine and I appreciate the discussion.
No, please, do not spread FUD. This cryptocurrency cannot be traded today because the airdrop give you access to it after 2 months, thus, no one has it. You are misleading people into letting them believe that real trades are happening, ask yourself who possess that currency.
People need to understand that those scripts are not doing anything weird to their private SSH key material, if you want to guarantee this, feel free. I am just telling people this is not trivial.
In addition, you need to pay your own money and get this ETH thingie.
Thus, this is quite different from the Starknet situation, yes.
It appears to me that you have missed washy trades are ongoing, I would recommend cautiousness if you don’t have background in those fields, especially when it comes to advertising other people to take actions regarding this. As you mentioned my name and conflated the previous approach, I must clarify.
I hope my clarifications are clear, I unfortunately do not have enough time to expand much further.
Does their claim page allow a single wallet to receive multiple FLT-DROP claims? (Aka, could a community member collect proofs and aggregate them into a single eth wallet?)
Presumably this proof becomes public, thus there is a public record of my drop claim and later receipt of these tokens? I don’t know what other global side-effects this may or may not have, depending on one’s citizenship(s), the legitimacy of FLT, etc, etc, etc.
I’m not sure I’ll commit to this given my last unknown, but I’ll keep an eye out in case someone volunteers to collect, aggregate, and donate the FLT-DROP claims to (the same set of donation targets as in the Starknet case).
Yes, they did age --encrypt a challenge using your public keys from GitHub as recipients, which means that you “only” have to age --decrypt it. If you’re using a YubiKey, it’s very likely that age-plugin-yubikey will “just work”.
Judging from the source code on Etherscan it is not possible for one Ethereum account to claim multiple times. See DevRewardDistributor.sol:205 which checks that there is no unlock time set on locked balances and DevRewardDistributor.sol:223 which just writes to locked balances, when in the case of multiple claims this would have to be an additive operation.
So, we cannot just use one account directly, but would have to create one per donation. Creating new accounts is rather straightforward. The complication is that each of those accounts would have to receive some small amount ETH (in the range of 5-10 USD) in order to pay for the execution of the smart contract. This might be prohibitive, since some entity would have to pay these fees in advance. Since it’s completely unclear what 5000 FLT might be “worth” in two months, it’ll be very hard to find such entity. Individuals might be okay with risking 10 USD for themselves, but probably won’t risk multiples of that if we’re talking, say, tens of community members wanting to donate.
Thanks for asking this question. I did think about it before, but didn’t actually go and read the source. I was a little lazy, trying to figure out whether there’s any interest at all before invest more time. I think this rules out a centralized donation effort…
The claiming call to the smart contract contains a user ID and is recorded publicly. However, checking the source code of the smart contract via Etherscan and Fluence’s scripts, you’ll see that this user ID is not the GitHub user ID. It is part of the encrypted secret in metadata.{bin,json}. So, whoever generated the challenges in metadata.{bin,json} (using age --encrypt --recipient ${FROM_GITHUB}), or whoever otherwise manages to obtain a mapping between a GitHub user ID or public key and the plaintext of the challenge, will be able to make the connection between a user ID on Ethereum, thus an Ethereum account, and a GitHub account.
Nothing stops Fluence from publicly releasing this information anytime. Hopefully they have securely handled and deleted it already. There’s generate.py which plausibly generated the challenges. If they really used that code, I don’t see how they would be able to reconstruct the mapping. There’s also this Gist, plausibly by a developer at Fluence, that explains the process to some extent.
Note that the claiming call also contains a “temporary address”, for which the same reasoning applies, except that there’s no potential for confusion with a GitHub-assigned ID, like there is with “user ID”.
Just looking at public information on GitHub and at public information on Ethereum, I don’t see how it’s possible. I could be mistaken and of course I don’t take any liability…
The plugin will not work, because it uses a dedicated age key generated on the key while they used the public ssh keys from Github profiles to encrypt the messages.
If you are using GPG keys on your Yubikey for SSH and happen to have a backup of the GPG key from which the public SSH key was derived, you can convert the private GPG key to a private SSH key and decrypt the message with it.
Right, right. I remember now, I had a whole idea about trying to convert GPG keys to PIV whatevers at one point in time, but even then, not sure about slot alignment, etc. I sort of gave up on this adventure since, it doesn’t seem like any of the open source security tokens really got to a point where I would trust them (physical-resilience wise, or PIV-applet wise).
To be honest, my… friend… is kind of uninterested. Given the (0) unclear legality for various citizens, (1) lack of ability to do this anonymously, (2) threshold required for accessing cold storage gpg backup, and (3) risk of being at a net-loss between the ETH account opening cost, and the unknown future value of a non-liquid token.
