Run ng serve for a dev server. Navigate to http://localhost:4200/. The app will automatically reload if you change any of the source files.
Code scaffolding
Run ng generate component component-name to generate a new component. You can also use ng generate directive|pipe|service|class|guard|interface|enum|module.
Build
After proper configuration of environment.ts and environment.prod.ts, run ng build to build the project. The build artifacts will be stored in the dist/ directory. Use the --prod flag for a production build.
Format
Formatting will happen upon commit. Developers can also run npm run format or npx npm run format if npm isn't installed to format all source files
Not sure under what circumstances this happens, but it seems to be related to how long it's been since access was originally granted. But sometimes when sending a decrypt message to identity, it's returning approvalRequired: true, even though AccessLevel: Full was requested and granted. This shouldn't be happening, full access should mean full access, and approval should not be required for anything.
I'm using this in a native mobile app with URL: "https://identity.bitclout.com/embed?accessLevelRequest=4&webview=true" and the decrypt message being sent is:
{
id: <some uuid>,
service: 'identity',
method: 'decrypt',
payload: {
accessLevel: 4,
accessLevelHmac: <stored hmac from login>,
encryptedSeedHex: <stored encrypted hex from login>,
encryptedHexes: [<array of encrypted hexes>],
},
}
When an application uses Bitclout Identity to get user access, it receives some kinds of tokens that can be used to access user info or depending on the access level, makes transactions for the user with/without his permission.
Does these tokens ever expire?
Is it easy for a user to check all the tokens he generated?
I am facing a weird issue! Somehow identity fails to show the window and the only console log I have is this
DevTools failed to load source map: Could not parse content for https://identity.deso.org/vendor/bootstrap.min.css.map: Unexpected token < in JSON at position 0
It would on occasion show the window content but usually the window is blank. I do get port messages and I see them in the console window but can't interact with identity at all Any ideas?!
Not sure if this is a bug, a limitation, or a design decision. When using identity to decrypt DMs, it only seems to decrypt the received DMs, and not the ones that the user has sent to the conversation.
bitclout.com seems to be storing the sent messages in local storage before they get encrypted, and that's how they're able to be rendered in the conversation.
My gut is telling me this is probably because they get encrypted using the receiving user's public key, and therefore require that user's private key to decrypt, and because the sender doesn't have that private key, they can't be decrypted?
Just wondering if there's anything that can be done about that, or is the only option to cache the unencrypted messages client side before they get sent? This would mean that if the browser storage (or app storage if using a native app) was cleared, those messages would be lost forever to the person who sent them.
As far as I can see, the only way to interact with the identity service such as receiving data after a successful login or to request the signing of a transaction is to post/receive a message on the window event listener. Presumably the intent is for web apps to run Identity in an iframe and communicate through that event listener.
In a native mobile app, if we navigate the user to identity.bitclout.com in an iOS WKWebview or Android CustomTab so that they have a secure environment to login then there is no way to interact with the window event listener.
Similarly when we want to sign a transaction there is no mechanism to post an event to have identity sign the transaction hex.
Am I missing a mechanism that exists for native mobile apps to interact with Identity?
Deso identity works when I use ng serve command.
But when I use ng build --configuration production and copy the dist folder to my server and then use Deso identity from there, I get the below error https://myDesoIdentity.com/embed?v=2 not found.
I'm checking the feasibility of signing transactions but only submitting them conditionally. For this use case I have two questions:
When the user signs a transaction, he receives a TransactionHex that can be submitted to confirm the transaction on chain. Does this TransactionHex has any kind of expiration or can be used forever and still work as long the user has the necessary clout to perform the operation?
Once I received a signed TransactionHex from the user, is there a way to check if the code is valid without confirming the transaction?
In the returned payload, the "transactionSpendingLimitHex" is undefined, all other properties contain correct data:
function handleDerive(payload)
{
if (identityWindow)
{
identityWindow.close();
identityWindow = null;
var publicKey = payload.publicKeyBase58Check;
var derivedPublicKey = payload.derivedPublicKeyBase58Check;
var derivedSeedHex = payload.derivedSeedHex;
var expirationBlock = payload.expirationBlock;
var accessSignature = payload.accessSignature;
var transactionSpendingLimitHex = payload.transactionSpendingLimitHex;
If on step 2 you click on an already logged user, the payload contains the correct "transactionSpendingLimitHex" data
I originally posted this in /frontend, but it was the wrong place. We're having an issue on Safari desktop with approvalRequired on the React web app we're building. I understand that Identity needs to request access again 1 week after login, but we are finding that even after approval is given, and the cookie is updated, Identity continues to request access for every transaction thereafter. i.e.:
Given that I'm using Safari
And I logged in 1 week ago with access level 4
When I attempt to buy a coin
Identity requires me to Approve transaction
And when I Approve transaction, then it is successful
But when I attempt another transaction
Then Identity asks for approval again
Despite the fact that the seed-hex-key in Cookies was correctly updated to last another week (i.e. now to expire 2 weeks from when I originally logged in)
We'd appreciate if you could look into this or provide some insight.
I'm getting the JWT and the public key of the user, but I need at least a username and profile picture.
Is there a way to get them? I saw that you have an endpoint in the backend-api.service, that returns the username and the profilePic (GetUsersStateless) - is there a way to consume this from our webapp?
At the file identity/src/app/approve/approve.component.ts in generateTransactionDescription(), when the case is a TransactionMetadataBasicTransfer, the display message is all wrong.
It shows total amount of nanos in the transaction including ChangeAmountNanos which is misleading. It should only be SpendAmountNanos.
The public key displayed is the sender's whereas it should be the recipients
When I use the /v0/send-bitclout api route to send 0.1 bitclout worth in nanos from BC1YLiXsLZvrySthVJPJozLr3rMSo2BARZ4VG525bhbsAJCTvwJQJCe to BC1YLh4R1ewSLphyWncnUsRmJ5okAn4xjRMUHD5Q6vVd5ZAYgf8zWZo, I get the following message:
localhost wants to send 0.203897603 bitclout to BC1YLiXsLZvrySthVJPJozLr3rMSo2BARZ4VG525bhbsAJCTvwJQJCe
I have a couple of alt accounts and anonymous accounts in my DeSo identity on my mobile phone. 2 days ago i noticed that one of my anonymous accounts became active 43 days ago as the account @mayadoesart (the daughter of @VindictiveTJ according to the profile info).
It looks like she generated the same private seed phrase as my anonymous account. I'm so lucky I didn't ever used this account to hold my DeSo or NFT's in it, and no one was harmed by this event.
SubmitTransaction: Problem processing transaction: VerifyAndBroadcastTransaction: Problem validating txn: ValidateTransaction: Problem validating transaction: : ConnectTransaction: : _connectBasicTransfer: Problem verifying txn signature: : RuleErrorInvalidTransactionSignature
I am doing it by access level 4 identity login approach:
Am I not supposed to sign transaction with encryptedSeedHex & TransactionHex while attempting from fetch API? Like in service worker, I can't use deso sdk directly rather I can have signTransaction function.. so what I did is made a function named sendDiamonds where I put payload for sendDiamonds and got response of TransactionHex & more from it. Used that TransactionHex with encryptedSeedHex to sign the transaction & made a POST request to submit-transaction endpoint
I'm trying to use Bitclout Identity on my application and I'm having some problems/concerns about security:
1 - When I try to send accessLevelRequest I don't notice any change in the interface or the final access level authorization. I'm opening the following URL: https://identity.bitclout.com/log-in?accessLevelRequest=2.
It doesn't show any message that explicit to the user the level of access and after the user authorizes it always return me the access level 4.
I also tried using accessLevelRequest=AprovaAll. Am I using the wrong URL or this feature isn't complete yet?
2 - When I'm logged on many user accounts at the same time and use the identity window, it returns me access level 4 for all the logged accounts. Even when I'm selecting just one account. Shouldn't return only the requested level access for the only selected account?
I switched from localhost to my private IP address to get the issue resolved where access levels were not showing properly. In localhost, all access levels are set to 4 by default.
Even when testing from an IP address with permission level set to 3, Identity is prompting for approval for everything, even non-monetary transactions (e.g. posts).
In addition, Identity is prompting for approval when requesting a jwt token for the user. The jwt token is necessary for any type of image upload. However, Identity will not return a jwt, it only returns {approvalRequired: true}.
main-es2015.7fd4f7fb2e638fd391c6.js:1 ERROR TypeError: Cannot destructure property 'service' of 't' as it is undefined.
at e.handleMessage (main-es2015.7fd4f7fb2e638fd391c6.js:1:1661185)
at main-es2015.7fd4f7fb2e638fd391c6.js:1:1657249
at u.invokeTask (polyfills-es2015.f888aaa0bd730994945c.js:1:20709)
at Object.onInvokeTask (main-es2015.7fd4f7fb2e638fd391c6.js:1:1417062)
at u.invokeTask (polyfills-es2015.f888aaa0bd730994945c.js:1:20630)
at a.runTask (polyfills-es2015.f888aaa0bd730994945c.js:1:16118)
at l.invokeTask [as invoke] (polyfills-es2015.f888aaa0bd730994945c.js:1:21759)
at f (polyfills-es2015.f888aaa0bd730994945c.js:1:33720)
at h (polyfills-es2015.f888aaa0bd730994945c.js:1:33965)
I'm using identity in a WKWebView on a native iOS app running on iOS 14.5.
When using login with google, the behaviour seems a little strange. I've been able to sign in ok, but when trying to use the Login with google button again to log in to a separate google account, it just hits an infinite spinner and never progresses. The only way to resolve the issue is to uninstall and reinstall the app (which clears any storage associated with the browser inside the sandbox, so it's a clean slate). I've attached a screen recording to demonstrate the issue.
Screen.Recording.2021-05-31.at.14.58.00.mov
The recording was taken using a simulator, but things get even worse on a real device. On device, I just get the following error message from Google:
Additionally, the App Store review guidelines state:
4.8 Sign in with Apple
Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option. A user’s primary account is the account they establish with your app for the purposes of identifying themselves, signing in, and accessing your features and associated services.
Sign in with Apple is not required if:
Your app exclusively uses your company’s own account setup and sign-in systems.
Your app is an education, enterprise, or business app that requires the user to sign in with an existing education or enterprise account.
Your app uses a government or industry-backed citizen identification system or electronic ID to authenticate users.
Your app is a client for a specific third-party service and users are required to sign in to their mail, social media, or other third-party account directly to access their content.
It's possible that it might be ok on the basis that bitclout is a 3rd party service, but it will probably at least be a debate. I could see Apple digging their heels in and saying that since the google sign in is optional, and not required, that sign in with apple must also be presented as an option. I understand why it's not, but I'd rather not have to fight that battle in order to push a bug fix out.
A potential solution to all of the above might be to allow apps to specify a query parameter to the identity URL, e.g. allowGoogle=false to simply hide the log in with google button, which would let us opt out of that functionality until such a time as we can fully get it working. Currently we're not going to be able to update our app without adopting this.
As the Derived Key implementation is not clearly documented, I thought derivedSeedHex would be interchangeable with seedHex; thus, I copied the implementation provided in this repository (including src/lib/ecies/index.js) and configured it on a React Native project running on top of Expo.
After fiddling around to make the crypto, buffer, and stream implementation load correctly, I tried it with my own seedHex (directly out of my browser's localStorage).
Everything seemed to be working; however, as soon as I replaced the seedHex with the derivedSeedHex (given by doing the derived authorization flow on the identity), the implementation started to throw the following error:
[Unhandled promise rejection: Error: Incorrect MAC]
at src/lib/ecies/index.js:26:1 in kdf
at src/lib/ecies/index.js:170:2 in decrypt
at http://127.0.0.1:19000/node_modules/expo/AppEntry.bundle?platform=ios&dev=true&hot=false&minify=false:192892:18 in decryptShared
at src/pages/Inbox/index.tsx:41:20 in useCallback$argument_0
at [native code]:null in flushedQueue
at [native code]:null in invokeCallbackAndReturnFlushedQueue
The error comes from the following section, and removing it, will cause invalid encryption.
assert(hmacGood.equals(msgMac), "Incorrect MAC");
With that said:
Does the Derived Keys support decrypting messages? (or in other words, Am I doing something wrong?)
If they don't support decryption: when will this feature be available?
If they do support decryption: is it only from the messages encoded using Derived Keys?
All and all, how should I proceed to implement such a feature?
When using Mint Machine by nathanwells, I noticed that I can authorize a derived key once with global deso limit set to 1 DeSo (or something like 1.0001 to be exact - probably to account for gas fees), but then I can get several 1 DeSo bids accepted (by cloutpunk in this case) on that derived key.
So it seems like global deso limit for nft bid transactions - applies to the "act" of placing the bid, so just the gas fees associated, and not to the amount of bids placed.
This does not seem to be the correct behaviour - I would expect that when authorizing a derived key to use NFT bid transactions, with a global deso limit of 1 DeSo, it's one of the 2 options:
I can place bids up to 1 DeSo, so if there is already a bid outstanding (not accepted) for 1 deso - I can't place a second one; if someone elses bid is accepted, and thus mine is deleted - then I can place another one up to 1 DeSo, or
regardeless of outstanding bids, the total amount of accepted bids on this derived key, cannot exceed 1 deso - so it's 1 cloutpunk @ 1 deso, or 100 other NFTs at 0.01 deso each