Looks really good, I support this! I wouldn’t wait on the resolved limitations, rather propose something thats finalizable, then make a follow up once possible.
4 Likes
fully agree on that. but I would consider to change the contract in that regards once this is possible 
Sounds promising, looking forward seeing where this goes. I think the diagrams approach could lower the understanding barrier.
4 Likes
really good, thank you for sharing with us
1 Like
Dear @marco.chain, thanks for the interesting application. Can you please contact me for the details? Please note the maintenance should be at least one year provided.
1 Like
Hey @lydia, I will come back to you soon.
My proposal has different phases where maintenance might not be so much relevant. I think most important is Phase 1 and 2. For phase 2, the contracts I do not see much relevance for maintenance. It would be more like new features to be added (e.g. delegation of all AENS names once this is possible).
The maintenance part would be more relevant for Phase 3 / 4. I am not even sure if I want to apply for Phase 4 of this proposal. There might be another team that could tackle this part as I am neither a designer, nor a good frontend developer. Phase 3 could be easily handled by me with a just functional UI that allows to interact with contracts.
Regarding maintenance I am currently watching the discussion here: [Withdrawn] Governance Aepp Improvements - #7 by philipp.chain
I think it should be clear what kind of maintenance is expected. As @philipp.chain outlined it could be a tiny effort, but it can also be a bigger effort if there are breaking changes in SDKs for example.
2 Likes
Dear @marco.chain,
thanks for the explanation. Please put project hours per scopes in order to estimate the cost. Since the scopes are depending on each other and some are optional please specify the deliveries of the scope 1. and scope 2. for any user. A discussion in the forum on the known limitation and diagrams of your project can be recommended before the start of the project.
The maintenance requirement for the software project is needed to provide a quality software and documentation at least for a year. Some of the Chinese developers even confirmed and are doing the maintenance for several years. The goal of the software maintenance is to keep the software system working for the users. If a developer feels not responsible for the bugs created by him/her and requires at least double payment for the same task it arises the question for whom the broken software can be useful (who controls at the end the project cost). Please feel free to contact us under the Email: [email protected]
Hey @lydia,
I just updated my grant application and also provided and approximate amount of hours on each phase. As I am solo developer on this I removed phase 4 and made phase 3 non-optional. I think a UI that allows to interact with all available contract entrypoints is mandatory for people to actually use it.
The estimates for phase 2 and 3 are very vague as long as phase 1 is not finished. It heavily depends on how many features we want to cover and how complex the proposed solution will be.
I will also reach out to you via e-mail.
2 Likes
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