thank you for sharing with usverizon internet login
mobdro app
Cool 
Will let you know once I start and provide weekly updates then.
1 Like
I was finally able to sort some stuff out and will start working on this beginning of next week.
will keep everybody updated here!
3 Likes
I have 1705 aens and it’s a hassle to update them individually. Look forward to your update.
ak_hdkfdg8eHC4QyxMScYCFZTaqubwwGcw1dNynYqRQJ1ibJL1Kw
2 Likes
Hey everybody,
I just published a page where you will be able to track the progress of this grant:
Right now the most important thing for me is to clarify the scope. We can consider A LOT of stuff which might be cool, but to achieve it the right way I need to get as much feedback as possible. Otherwise I will probably have to stick to a minimalistic approach to avoid unnecessary overcomplication of tasks.
I created an Ideation Mindmap (Source: aens-nfts/ideation-mindmap-source.md at master · marc0olo/aens-nfts · GitHub) where I noted down all of my initial thoughts.
I will shortly summarize the most important questions to address and discuss:
- Do we want to introduce a mechanism to reward other users for extending AENS names of others? Personally I think this would be cool and this has always been in my mind
- What reward-mechanism do we prefer?
- NFT owners define their own reward (in Æ coins) for users
- We create an AEX-9 token (e.g. AENS DAO) which rewards users based on various criteria (to be defined)
- I already noted some ideas in the mindmap about the AEX-9 token, but if we create such token we should also discuss its utilities (e.g. voting, staking, …)
- Both?! → IMO, if we decide to introduce an AEX-9 token, we should focus on that
- Do we want to allow transfers of AENS names between NFTs? Shall this only be possible if the user is owner of both NFTs? I would say yes
- Logic for extending AENS names wrapped in NFTs (and possibly corresponding reward-payout logic)
- Always extend all names? (most simple solution, especially when it comes to rewards. but not really efficient)
- Select a set of names to extend?
- Select a single name to extend?
- Do we want to limit the amount of AENS names that can be wrapped into NFTs to ensure that batch-updates & batch-transfers are always possible for all wrapped names? Or should we allow an unlimited amount of names to be wrapped where users/devs would have to take care to not exceed limits in batch updates?
- How to deal with “spent” or “accidentially received” AENS names? The Smart Contract would not be able to know who sent the AENS name to its account, so there are following options:
- Sell
- who should receive the sale proceeds?
- Listing vs. auction
- Fixed price vs. dynamic price
- Make claimable by anybody (first to claim gets the name)
- Let expire
- Sell
In case we decide to introduce an AEX-9 token we will have to discuss a lot more details. But these are the “big questions” I have currently in mind which I want to discuss with you.
Can’t wait to get some feedback!
3 Likes
I think I definitely want to provide some incentive mechanism for users to extend AENS names of other people.
the key question is then what route to choose:
- let AENS owners pre-fund NFTs with AE and define a reward for extending names
- introduce a new AEX-9 token and implement some protocol to reward active users
the first option would definitely the more straight forward solution and NFT owners can then define how much it is worth for them if others extend AENS names on their behalf.
introducing a mechanism to issue a new AEX-9 token for the reward system comes with a lot of additional questions I am not sure if we’d be able to address right now. it’s probably better to think about this at a later stage if we see that there is a lot of demand for the application in general.
currently I think it’s best to go on with the route to let all NFT owners decide themselves how to reward other users.
the other topic I am a little bit struggling with is how to deal with AENS names and different expiration times. probably it would be best to always keep them in sync, so that all names have the same expiration time. this would also mean that if additional names are added to an existing NFT, all names associated with this NFT would automatically have to be extended along with the name(s) to be added.
in this case I would also prefer to only allow extending all wrapped AENS names at once for reasons of simplicity & to keep expiration time in sync.
only following explicit actions for single AENS names or a set of AENS names would then be possible:
- transfer from one NFT to another NFT, which in turn would then automatically extend all AENS names wrapped in the target NFT
- claiming back AENS names from an NFT to a specific account
- setting individual pointers
extending names would only be allowed for all AENS names at once. this also means that we have to introduce a limit of AENS names that can be wrapped in an NFT. we need to ensure the actions to update all names do not exceed the gas limit.
any other thoughts on that?
1 Like
I’d love to see an AENS DAO with an AEX-9 token here, probably with multiple functionalities that allow to burn such token. I’m wondering if it could be a DAO with a staking business model given that this is an AF grant or maybe it’s not relevant at all.
I think it should be possible even if the user doesn’t own both NFTs.
Always extend all names at all I would say, else it becomes too many steps for the user I believe. Ideally try to have a smooth UX for end consumers. In any case users should be able to see at a quick glance how much it would cost to extend all names of one NFT or another.
Unlimited amount, but always given that users can see the costs for batch extending names for each given NFT.
Hmm maybe this should be decided via voting in the DAO model. I’d personally prefer the first come first, serve model to allow people to claim names they lost by accident
I’d personally prefer the second route in a DAO model with staking incentives, I know it’s more complicated to develop, but will allow more user engagement I believe.
2 Likes
I agree in general, I would also love to see this. but I somehow doubt that we will be able to iron out all the details within the scope of this grant. too many questions to answer which I am not sure how to deal with:
- when will new tokens be issued?
- will there be a cap of tokens or will there be an infinite (but reasonable) inflation as incentive to participate in the system
- how to prevent “cheating” (mass-creation of tokens) in case of usage based issuance
- what can the token ultimately be used for? what is the utility?
- if we aim for DAO capability it might anyway be good to wait for the results of the running hackathon
- if there is no utility for the issued token which is rewarded to accounts when extending other accounts, why would they want to extend the names then? so this is a very crucial aspect in that regards.
- if we aim for DAO capability it might anyway be good to wait for the results of the running hackathon
for this reason I tend to choose the other route first, letting NFT owners define a reward for extending names. of course the system can be improved in the future and maybe we can then introduce the AEX-9 issuance and establish a DAO for this. right now I feel there are too many open questions and uncertainties 
I mean in the end I wanna ship the solution as soon as possible 
and additionally we don’t know yet how many people are really interested in using this. I hope and assume there will be at least some demand
can you name examples where you would expect that to be possible? maybe the NFT owner could define a flag if he accepts AENS names of other accounts to be wrapped into an existing NFT he owns 
I can definitely imagine that some people would want to avoid this. otherwise I could spam AENS names into other users NFTs.
regarding costs: this would be the default network fee for the transaction. in fact, the user is anyway expected to get a reward (only if the user is not owner of the NFT of course). the more names are wrapped in the NFT, the higher the tx-fee.
actually I think we have to introduce a limit. if there are too many AENS names wrapped in an NFT, extending names tx could exceed the gas limit. that would be a flaw in the contract then. of course I would perform tests and allow as many AENS names as possible to be wrapped.
I don’t think DAO will be doable in the scope of this grant as explained above. I agree that first come, first serve model is best.
maybe we can introduce a fixed fee for claiming that name and send the AE to the BRI wallet to support the work of the foundation although I doubt this scenario will happen a lot 
I currently favor the first route as I outlined above. but I am open to hear more opinions on that. we still have some time to discuss before I finish the diagrams and aim to start developing. independent of that any idea is welcome and we can introduce a DAO model at a later stage
2 Likes
I think besides the Nft attribute, Aens also needs to be considered as an identity and domain name. From a domain level perspective, I hope .chain can replace.com in the future. You can use Aens as a fully decentralized website (ideally not attacked or blocked by government or other entities), I also hope that all dapps on aeternity can be accessed through .chain and from an identity perspective, I hope that Aens can be used as a social media account (such as for logging into superhero）, or an email account (such as a decentralized email system based on Aeternity for account login), game account, or game character name, etc
setting arbitrary strings as pointers will be possible once Ceres hardfork is activated. definitely the naming system can support a lot of use cases, but it is up to developers and businesses to utilize this feature
2 Likes
I have updated the diagrams and I am currently aiming for the “simple” approach which allows any user to set a global reward config as well as an NFT specific reward config.
read more about rewarding users for extending names here:
also, I have added a sequence diagram which showcases an example where almost all possible actions are executed:
Waiting for more feedback now. Will define the concrete contract interface based on the current state early next week and if nobody raises concerns I would start with the implementation right after that. At least I will analyze the max. amount of AENS names that can be wrapped into an NFT based on the current proposal.
Maybe there will be some iterations required in development, but I think that’s ok.
Additionally I found sth. interesting recently which we might take a look at in the future. This is brand new stuff and has been announced 2 days ago:
https://twitter.com/AlchemixFi/status/1649085593257668608?s=20
Alchemix has build a solution for ENS that allows users to never lose their ENS names again. This is actually sth. I would also like to focus on here. But let’s start with a simple solution first and get it out in the hands of the users
2 Likes
Week 16 (Apr 17 - Apr 23)
- repository set up with MkDocs: GitHub - marc0olo/aens-nfts
- ideation mindmap
- several diagrams based on first ideas and forum discussion
- full example sequence diagram
Time spent: 22.00
2 Likes
here the currently proposed contract interface that extends the AEX-141 standard interface:
again, any feedback is appreciated! 
3 Likes
I just got some very valuable feedback from @hanssv.chain and discussed several things with him. I will consider following things:
- fix
revokeAllnaming- I accidentially used
revokeMultipletwice
- I accidentially used
- allow minting of empty NFTs
- previously I didn’t consider this
- this would allow to set up empty NFTs where the owner or somebody else could add / transfer AENS names to
- add config param to allow/prevent receiving NFTs of strangers
- will use
reward_configfor this and rename it just toconfig - if no config is set, receiving NFTs of strangers is considered not to be allowed
- will use
- a more restrictive SPAM prevention where delegation signature for a specific name can be handed over off-chain to the desired new owner who then can use this signature to just “claim” the name to one of his NFTs
- don’t extend all wrapped names by default, instead perform an update on the transferred names to match the expiration of the already wrapped names
- this is a way more efficient approach
- we agreed, that expiration consistency of all AENS names wrapped into a specific NFT makes sense
2 Likes
diagrams & contract interface updated accordingly 
2 Likes
1 Like
Week 18 (May 1 - May 7)
- updates to contract interface & diagrams
- development setup
Time spent: 3.5h
Week 19 (May 8)
- development setup
- empty but compilable contract implementation of
IAENSWrapping.aes
Time spent: 2.5h
Total time spent for scope 1: 38.5h
As of today, I consider phase 1 (scope definition) finished and will start with phase 2 (contract development).
At start of phase 2, I will also do some gas calculations to define appropriate limits.
2 Likes
Making some progress 
/// @notice wraps AENS names into a fresh minted NFT, adds NFT metadata, extends all names
/// @param names_delegation_sigs a map (key = AENS name, value = delegation signature)
/// @return the NFT id
stateful entrypoint wrapAndMint(names_delegation_sigs: map(string, signature)) : int =
let token_id = mint_internal(Call.caller, None)
let names_delegation_sigs_list: list(string * signature) = Map.to_list(names_delegation_sigs)
List.foreach(names_delegation_sigs_list, (val) => claim_and_assign(val, token_id))
token_id
describe('AENS Wrapping', () => {
it('wrapAndMint', async () => {
await claimNames(aensNames);
const namesDelegationSigs = new Map(
await Promise.all(
aensNames.map(async (name) => [name, await aeSdk.createDelegationSignature(contractId, [name])])
)
);
await expectNameOwnerProtocol(aensNames, aeSdk.selectedAddress);
await expectNameOwnerContract(aensNames, undefined);
await expectNameNftId(aensNames, undefined);
const wrapAndMintTx = await contract.wrapAndMint(namesDelegationSigs);
console.log(`Gas used (wrapAndMint): ${wrapAndMintTx.result.gasUsed} for ${aensNames.length} names`);
await expectNameOwnerProtocol(aensNames, contractAccountAddress);
await expectNameOwnerContract(aensNames, aeSdk.selectedAddress);
await expectNameNftId(aensNames, 1);
const nftMetadataDryRun = await contract.metadata(1);
assert.equal(nftMetadataDryRun.decodedResult.MetadataMap[0].size, aensNames.length);
});
});
});
Claiming 2 names for ak_fUq2NesPXcYZ1CcqBcGC3StpdnQw3iVxMA3YSeCNAwfN4myQk
Gas used (wrapAndMint): 42793 for 2 names
✔ wrapAndMint (3911ms)
AENS wrapping limit per NFT
As previously discussed there will definitely be a max limit of AENS names to wrap into an NFT. I am wondering about the desires of the community in that regards.
Let’s assume we can add a lot of AENS names into an NFT. How many names would you like to manage within an NFT for batch updates etc.?
Currently I am considering to keep it quite low with ~21 AENS names (I like the number ). Of course I could also make it configurable and increase later on.
For wrapping only, each additional name consumes 12692 gas according to current logic. Of course we also need to make sure that other entrypoints with different actions (especially updating/extending names) won’t run out of gas, too.
Looking forward to hear what the community thinks about the AENS limit
2 Likes