https://docs.near.org/docs/concepts/account#account-id-rules says that account IDs must be 2 to 64 characters, and currently MIN_ALLOWED_TOP_LEVEL_ACCOUNT_LENGTH = 32, so top-level accounts of 32 to 64 characters are available without needing to be purchased at auction.
It also says:
Currently all mainnet accounts use a near top-level account name (ex example.near)
My guess is that "currently" means not just that there don't happen to be any other top-level accounts now but that there cannot be until a future change in NEAR protocol.
Where can I see the source code related to this statement?
And is there a public roadmap / timeline somewhere stating when (auctioned and non-auctioned) top-level accounts will become available?
given how account and account names are implemented (an account is actually a smart contract) the use of "near" as as a root-level account is needed.
".near" is actually an account with a smart contract deployed on it:
https://explorer.near.org/accounts/near
Anything related to account id (names) can be found here:
https://github.com/near/nearcore/blob/master/core/account-id/src/lib.rs
Related
Runtime Specification listed here: https://nomicon.io/RuntimeSpec/Scenarios/FinancialTransaction#transaction-to-receipt states within the verify_and_charge_transaction method, one of the operations is supposedly to:
Checks whether after all these operations account has enough balance
to passively pay for the rent for the next several blocks (an
economical constant defined by Near Protocol). Otherwise account will
be open for an immediate deletion...
Is this referring to an attempt to overspend from an account? Just curious on what warrants an account deletion in this case?
Yes, this is checking that the account does not overspend. The account balance afterwards has to be above the threshold required for storage staking.
The check gets called here, at which point the tokens have already been subtracted locally: https://github.com/near/nearcore/blob/aad3bf2adc1b07df9dd6321d8e1faefbe50afe9c/runtime/runtime/src/verifier.rs#L160-L172
And the source code for the check itself: https://github.com/near/nearcore/blob/aad3bf2adc1b07df9dd6321d8e1faefbe50afe9c/core/primitives/src/runtime/mod.rs#L14-L42
Regarding account deletion, this is a just a hypothetical. If somehow there was not enough balance left to store the account's state, it would have to be deleted immediately. Deletion here means removing all its state from the chain's state. That includes all access keys, hence you would no longer be able to use that account. (You or someone else could claim it again, though.)
But to be very clear, there is no circumstance where this actually happens. Overspending is always prevented and can never lead to an automatic deletion.
I have a question. Outlook add-in.
The itemId value is strange from 3 days ago. We are using the office.js provided by Microsoft.
It was developed as an official document.
Issues
The results for Office.context.mailbox.item.itemId code are different on mobile and PC.
Mobile
AAkALgAAAAAAHYQDEapmEc2byACqAC/EBBBBBBiI2N+M9RJ0CDShuowvXKcwACJekCOwAA
PC
Result: AAMkAGM1ZDc2YjFjLWExODUtNGVkNC1hNDBBBBABEAMSxr1XgSL8NM2 + Hy8n2BwByK7vlr7ySQpFsplYmphCiAAAAAEMAACIjY34z1EnQINKG6jC9cpzAAIl6LODAAA =
The same code, but the results are different.
Thank you for your reply.
There are two kinds of entry IDs:
A short-term entry identifier is assigned by a service provider to an object when the identifier must be constructed quickly and does not need to last over time or distance. The uniqueness of a short-term entry identifier is guaranteed only over the life of the current session on the current workstation. Typically, a short-term entry identifier is valid only until the object that it represents is released. Clients quickly acquire, use, and discard short-term entry identifiers. For the most part, they can be used in the same manner as long-term entry identifiers.
A long-term entry identifier is assigned by a service provider to an object when an object requires an identifier with a prolonged lifespan. Long-term entry identifiers are always valid for weeks or months and can be valid on other workstations, depending on the provider. The long-term identifiers created by address book providers for custom recipients are universally valid. Long-term entry identifiers must be unique across all message stores in the active profile; therefore, when a message or folder is copied from one message store to another, it must be assigned a new entry identifier. When a message store object is moved, the message store provider that implements the move determines whether the original entry identifier will remain valid. Some service providers assign new entry identifiers to moved objects; others do not. If there is a change, the new entry identifier will be included in the information passed to clients when they are notified of the move.
We have exactly the same problem.
Worse it that it is currently different on one mobile device to another. i.e. some mobile devices are still returning the long code and consequently are working.
I don't overly care about getting a 'short code' but you can NOT reference the object using the 'short code'.
Therefor 'short code' = Broken Microsoft Outlook on mobile devices.
This is not a "minor" issue as it has rendered our plugin inoperable on mobile devices.
I have a few questions regarding the cordite dgl tokens.
I want to tokenize an asset which is represented as LinearState.
Is there a way to only allow a single issuance of tokens?
Is the preferred way to link the tokens to other states through the TokenSymbol?
What is the intended design of accounts? One Account per usecase or one per TokenType?
How do I query if a specific token already exists? Is the only way to query for an account and look at the result (so there is no function to search for balance by TokenSymbol)?
Thanks in advance!
Great questions, thanks!
It's not possible right now but it's definitely recognised as being desirable. It will require a change to the core which is fine. I think this work will require Corda 4, notably reference states and linear state pointer types for it to work. Notably, we will want:
a. There are so many ways of limiting issuance: not only by final amount, but also by distribution rate, signing parties (in the case where multiple are required for the issuance) etc. We need means of inserting the notion of finite issuance into the token type, optionally. This will be either adding additional fields to the existing TokenType. Or better, making TokenType open so that it can be extended. Another way is to provide a field to a base type or interface that will encode the contract rules.
b. we could transfer the token type as an attached StateAndRef, but we need to be conscious of the per tx storage, network, signing and verification cost of doing this. A better approach is to use the reference data feature in Corda 4 that we are eagerly waiting for.
If the other states are part of the same transaction that emits the tokens, then the linking is implicit. If the other state is not in the same transaction as the token, then linking for now, in Corda 3, would need to use TokenType descriptor. Alternatively, it can also reference a StateAndRef in the tx that generates the other state. The most efficient we think is to use Corda 4's reference states (scheduled for Dec/Jan this year I believe)
Accounts are designed to store tokens of multiple token types. They are really aligned for the business use-case and aren't limited by specific token types, unless you want to enfore that in the application layer.
Do you mean you want to get the balance of a TokenType across all accounts? You can certainly use the Corda's API to locate Tokens - this isn't exposed via Braid yet but could certainly could be. Another approach is to tag/alias all your accounts with the same tag e.g. { category:'all-accounts', value:''} You can then do a ledger.balanceForAccountTag({ category: 'all-accounts', value:''}) to get balances across all accounts. However, this returns the balances for all TokenTypes. What would the ideal API look like for you?
Context: I am deploying multiple Amazon Echos at a single location in different rooms. These echos are managed in Alexa For Business. These echos will share many parts of the same skill, but in our AWS Lambda function, several environment variables should be segregated between these. In particular, we inform the Echo users what the wifi code is for their room, which will vary between rooms (and which other rooms should not be able to access.)
What I'd like to do is have those environment variables filter by the Echos' DSNs. Is this possible?
Or is this better to do at the skill level? We considered that, but we're not sure how to get around the inability to use similar invocation names and we do want to use consistent invocation names due to simplicity in user training.
More info: Using Node.js 6.10 and a template based on this: https://github.com/Donohue/alexa
I am not a smart man. Please feel free to hand-hold me in your answers. Thanks for your time.
The context object holds a field named deviceId. This uid is constant on a per device per skill basis. That means it's different for different skills used by the same device. But it keeps being the same for one skill invoked from the same device.
You can use that data to partition your devices on skill level.
What I'd do in your specific situation is to auto-register a device in your DB with the first skill invocation from that device. Once it's registered you can manually edit the dataset and add a group, that this device is supposed to belong to.
Your skill backend (lambda) then checks, what group the device is in and delivers the according WIFI pw.
I have an app in iOS and android and I'm getting the user's location in both of them! With CoreLocation for iOS and Google Maps in android... After the location retrieval, we apply reverse geocoding, to get the locality out of them... Once we do, we perform equalTo queries to find photos of a specific location...
The thing is, there are occasions where the locality of iOS, is slightly different to android's! For example, "Palaiochori" in iOS and "Paleochori" in android! Observe that two letters are different!
So, whereas the location is the same in both devices, the equalTo query will obviously fail!
What I want to know, is if there is any way to create a type of query, where we don't check for equality. Instead, we check for similarity!
Notice, that we do use cloud code, so any server-side solution is acceptable and preferred!!
Clearly the location name can not guarantee uniqueness. Two possible solutions:
Ensure consistency of your database
Store a GeoPoint for these locations. When you already have Palaiochori in your database and a user finds himself in Paleochori, before saving a new object, run a whereNear() query to see if you have near places for that location.
If you have results within a reasonable radius, ask the user: Do you mean <list of near places>? The user will likely recognize the place with a similar name, and tap on it. This way you avoid duplication.
Use a consistent location database
As soon as you have lat/lng, you could use Google Places API to ask for places near that location. Google will return a Place object with a unique placeId that you can store in your database. The id is guaranteed to remain the same and can be used for your queries reliably.