Proof of Attendance Infrastructure

[jonathanlei]

Discussion thread for bounty: Proof of Attendance Infrastructure (PR)

Create a UI / library for event organizer to mint and distribute Proof of Attendance NFTs (with event metadata - <date, description, cover art...> embedded in memo field) on the XRP Ledger. Also, enable them to track attendees, attendance history and distribute rewards.

This bounty is currently open. Discuss below!

[spicycheeto]

Working on this now. However, the NFT-devnet credential generator button is no longer working. Is there a problem with the server?

Also, just to be clear, milestone #1 requires a class with the necessary functions to implement features used by the community event manager / tool?.

[connorjchen]

Hi, we believe the certs have expired for the NFT Devnet. We are working on it right now. In the meantime, feel free to use the regular Devnet (it has NFTs enabled, so it shouldn't be too different).

Update: NFT Devnet credential generation is now fixed.

[jonathanlei]

To answer your second question: A class would be a good option in terms of implementation. Please make sure there is sufficient documentation explaining each function.

[spicycheeto]

Sorry, I haven't had much time to work on this. I will have my version of the API finished on the 31st.

Here is the current status:

https://github.com/spicycheeto/XRPL-Proof-of-Attendance-Infrastructure/blob/main/README.md

Any input from you guys would be appreciated. Is my functionality right? what else could I add? Is this what your looking for?

[kuyawa]

Is this bounty still open? I'd like to make this proposal and see if it fits the requirements:

NFT TICKETS:

Requirements:

• Mint NFT tickets for events
• ie. Mint 10.000 nfts for a concert and sell them at diff prices
• People can buy one or many
• People can transfer them to friends/relatives/resell
• Tickets can have numbered seats
• Tickets can have price class like VIP, executive, business, coach, etc
• Tickets can be verified on entrance using qrcode, nfc, manual entry

Key features:

• NFT unique
• anti-fraud
• transferable
• handicap enabled
• mint on demand
• fees on event registration + tickets sold
• valid for X days (disney, conferences, etc)
• multiuser (buy 5 tix for a family in one wallet, five people enter at once with one validation)
• cancellation: refundable or reusable (future date)
• templates for tickets
• batch mint/transfer
• batch seating: section A seats 1..20, section B seats 21..30

V2.0

• printable for an extra fee
• discounts on qty sold
• discount coupons
• pre-sale
• artist tour, diff venues/dates
• venue map seat selection
• mobile wallet apple/android

It can be done for the budget available as V1.0
The rest can be done in Version 2.0

ETC V1.0: 1 month
ETC V2.0: 2 months

[jonathanlei]

Hi, the scope provided here (NFT ticketing for sale) is beyond the bounty scope (Proof of attendance token for free), but NFT ticketing is a valid potential use case of XRPL and NFT's, feel free to apply to the next wave of XRPL grants https://xrplgrants.org/ when the next wave opens if you have a more fleshed out idea.

[kuyawa]

Thanks, I'll stick to the basic requirements for attendance taking poap.xyz as example, definitely much easier

[spicycheeto]

Hello community, I have made a submission to milestone 1 for the proof of attendance infrastructure. Waiting on feedback before moving forward with other milestones and additional proposals.

Milestone 1 submission: https://github.com/spicycheeto/XRPL-NFT-Proof-of-Attendance-Infrastructure

Hopefully, this is a good start and meet expectations. There is still a lot more to do. I could use some help as well if anyone wants to group up in a team.

[jonathanlei]

Thanks for your submission! I will review this and give feedbacks within a week.

[tadejgolobic]

In my opinion, this is quite an issue: https://github.com/spicycheeto/XRPL-NFT-Proof-of-Attendance-Infrastructure/blob/2bec43614478d943a8d02ae16f471d41565fa566/backend/routes/nftRoutes.js#L44

Here, you expect that wallet seed / secret is passed to your backend service. In my opinion, this is a no go. I assume that nobody will want to pass wallet seed to your backend.

[spicycheeto]

Perhaps I could have an account hard coded on the backend for whomever runs the server. This was a design decision I made to complete milestone 1. I was thinking of when someone comes to collect the NFT. They will need to pass some wallet information or account details. Looking at poap.xyz they do it with a qr code for the xumm wallet. This passes the secret no? Haven't got this far yet, but a hard coded account on the backend makes sense to me. The application will need to have users and the users will need to be charged separately or something like that in order to mint because it charges a fee to the hard coded account.

…

On Wed, Nov 2, 2022 at 6:23 AM golobitch ***@***.***> wrote: In my opinion, this is quite an issue: https://github.com/spicycheeto/XRPL-NFT-Proof-of-Attendance-Infrastructure/blob/2bec43614478d943a8d02ae16f471d41565fa566/backend/routes/nftRoutes.js#L44 Here, you expect that wallet seed / secret is passed to your backend service. In my opinion, this is a no go. I assume that nobody will want to pass wallet seed to your backend. — Reply to this email directly, view it on GitHub <#19 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADTYOXPRAWE4FXYP3HKJXLDWGI6KFANCNFSM6AAAAAARBBR4MU> . You are receiving this because you commented.Message ID: ***@***.***>

[jonathanlei]

I agree with @tadejgolobic. XUMM is a better way to handle transaction signing without passing along secrets. You can create a payload and XUMM will return a link/QR code that you can pass back to the user to sign on their XUMM app, no secrets needed. Docs here: https://xumm.readme.io/

[jonathanlei]

@spicycheeto other than the wallet signing issue everything looks good so far, love the detailed documentations.
Frontend is starting to look good too.

[jonathanlei]

@spicycheeto one more thing: for minting multiple NFT's, it is best to follow the batch minting guide listed here: https://xrpl.org/batch-minting.html

[spicycheeto]

@spicycheeto one more thing: for minting multiple NFT's, it is best to follow the batch minting guide listed here: https://xrpl.org/batch-minting.html

Fixed this. The rest is coming this weekend with final documentation and uploads. WAAY faster to do it this way. Great suggestion. Thank you.

[jonathanlei]

Please also add tests, as it's required in milestone 1, thanks!

[kuyawa]

I'd like to be considered for the bounty, here is my project https://kollek.me
What are the steps to participate?

[jonathanlei]

However, the claiming method of minting on behalf of claimer is highly encouraged, since the process is easier and no offers need to be created.

[tadejgolobic]

That is actually not possible right? Currently it is not possible to create buy offer using NFTokenCreateOffer and amount 0. XRPL would throw an error. Amount must be greater than 0.

The amount must be non-zero, except where this is an offer to sell and the asset is XRP; then, it is legal to specify an amount of zero

In case you do sign and submit such transaction, you will get temBAD_AMOUNT.

The Amount field is not valid. For example, the amount was zero for a buy offer,

Source: https://xrpl.org/nftokencreateoffer.html

[jonathanlei]

You can specify the currency to XRP and set the price to 0 -

Amount Currency Amount Amount Indicates the amount expected or offered for the corresponding NFToken. The amount must be non-zero, except where this is an offer to sell and the asset is XRP; then, it is legal to specify an amount of zero, which means that the current owner of the token is giving it away, gratis, either to anyone at all, or to the account identified by the Destination field.

Source: https://xrpl.org/nftokencreateoffer.html#nftokencreateoffer-fields

[golobitch]

Yes, but this is for sell offer. Above, you were talking about buy offer :)

[jonathanlei]

@golobitch oops that is right my bad on misreading it :)
Then creating a sell offer with a price of 0 to the claimer and having the claimer accept would be the way to go. Unless you have other suggestions.

[kuyawa]

Here is the source https://github.com/kuyawa/kollek
Will keep working on the details

[spicycheeto]

Hey team,

I've implemented the batch NFT minting on a node.js backend per your requests. I will have the XUMM wallet method of collecting by Sunday. Is there anything else I need to do to complete milestone 1? what are the next steps? I have additional proposals i'd like to make but want to get paid for milestone 1 first.

[spicycheeto]

Please, my final updates will all be done this weekend. I have a lot of code clean up and documentation updates to make but the batchx method (function) should be working. Also, please note, this is just the backend. I'm no longer keeping an updated version of my frontend. This will be part of a new proposal.

[jonathanlei]

Thank you for implementing the changes, according to milestone 1, tests are needed to ensure the API is functional. Also, please clean up some of the comments (todo's) and add complete documentation (params to routes and functions) to make sure people using it can have clear instructions.

[kuyawa]

Here is my proposal for the API https://github.com/kuyawa/kollek-api
Here is my proposal for the UI https://github.com/kuyawa/kollek
Here is the site running in nft-devnet https://kollek.me

[tadejgolobic]

@jonathanlei how did you imagine that NFT claim will work?
For example, I have created an API, where the person who wants to claim the NFT need to provide his account and NFTokenId. After that, I create NFTokenOfferCreate, with that provided account as destination. Is this what you guys had in mind?

Because this means that basically anyone can claim NFT if it knows the NFTokenId :)

Or should event organizer somehow import wallet addresses into the API, and we create N requests with destination as this addresses?

[jonathanlei]

Additional milestone 4 ($1500) has been approved and added: Deploying a no-code tool for non-technical event organizers.
Check out the details here: https://github.com/XRPLBounties/Proposals/blob/main/bounties/0019%20Proof%20of%20Attendance%20Infrastructure.md

Milestones 1-3 must be completed and approved before claiming milestone 4

[spicycheeto]

I'm re-writing my API to work with Xumm. Any idea on how to do a bulk mint request to Xumm api?

edit: The only way I see to implement this is to have a master minter account owned by the site which mints on behalf of the user and issues to their account...with bulk requests.

[jonathanlei]

Yes having a central minter account would be fine!

[JustAnotherDevv]

I have created a basis for the proof of attendance system during recent hackathon https://xrplnft.devpost.com
Here are repos for early version of the app:

• Devpost page with more information https://devpost.com/software/xrp-nft-attendence
• https://github.com/JustAnotherDevv/XRPledgerAttendance
• https://github.com/JustAnotherDevv/xrpl_poa_nft_hackathon_server

Currently I am wondering if this project could be accepted for the bounty once I spend more time on fixing few issues:

• There was a problem with using XRPL library on the frontend with Vite so currently the account's seed phrase is passed to backend to transfer NFT.
• Some parts of the code needs rewriting, wasn't focusing on that during just few days of hackathon development
• Comments providing clear description of the functions should be added.
• There was some problem with passing images to the backend that are supposed to be uploaded to IPFS directly from UI. That could be fixed very easily.
• Landing page should be added.
• More features such as burning the NFTs that weren't redeemed after event ends, querying for the token holders, generating QR codes, integration with existing XRPL wallets etc.

[jonathanlei]

Congrats on finishing the Hackathon! This is a very interesting Proof of Concept with lots of promising starts.There are few things I've noticed that need to be changed for this to qualify for the Bounty:

1. The backend code looks good for batch minting and distribution, however, there needs to be more documentation explaining each endpoint's utility, params needed and tests need to be added.
2. The frontend ideally would connect to XUMM wallet for non-technical users, and the backend would produce payloads for the FE users to sign.
3. The frontend would need better design since this will be a public facing tool for event organizers.
4. There are two milestones (Event attendees lookup and Event NFT ownership verification) that are missing from your backend, please reference the bounty document
   That being said, once you finish documenting and testing the backend API, please let me know and we are happy to review it, and if it passed the quality check, we are happy to pay out the first milestone, thanks!

[JustAnotherDevv]

Hey @jonathanlei I have updated my project after hackathon.
Now it includes features for first 3 milestones, the project is separated into class and example expressJS API.
There are proper comments, tests in Mocha and documentation. You can find the repo here - https://github.com/JustAnotherDevv/Attendify_XRPL.
It would be great to get your feedback if this submission meets all criteria.
I am also wondering if it make sense to add features related to more sophisticated configuration like whitelists, deadlines after which it's not possible to claim NFT etc or should those features be added as another milestone.

[jonathanlei]

Having reviewed your bounty with @JST5000 and @ckniffen , you’ve made a lot of great progress!

We had a look and here’s what you’ll need to do for each of the milestone components:

For milestone 1:

• Currently it seems that this will only work with testnet, but the api needs to work with mainnet addresses as well. Can you please add a way for the minter to set their issuing account? (Maybe by pulling a secret key from an environment variable?)
  • Currently the eventId is the minter address which won’t work if a single minter has multiple events. You should generate a separate code per batch mint operation to allow one minter to have multiple events.
• getBatchNFTokens currently could get the wrong result because it doesn’t paginate through responses from the server. Servers only send the first couple results, then if you want more you have to keep asking. More details here: https://xrpl.org/markers-and-pagination.html
• You can only have 250 active tickets. The code does not take into account batch minting over that amount or if the account were to have active tickets already as could happen with concurrent requests.
  • One other thing to note is that 250 active tickets can cause a large reserve requirement (Currently 2 XRP per object, so 500 XRP for just tickets)
  • To deal with this, you may want to check account balances as well to make sure you don’t accidentally try to make too many objects - although that may be something you correct with documentation in the README “You must have at least X XRP in order to use this to handle the reserve requirements for the NFTs and the minting process which uses Tickets.”)
• The REST methods should be documented (preferably in the README.md) so that people who are using the repo can tell what the interface is for the endpoints.

Questions:

• Why is the minter added to the claimableAddresses array? (It seems weird that the minter would be able to claim their own NFT - is there something else it’s doing?)

For milestone 2:

• Currently you’re using in-memory storage to keep track of who has already claimed an NFT, but if the server goes down you end up losing all of your data. So, you should use a more permanent state to check if they are able to claim the NFT to avoid duplicate claims.
  • One way you can solve this is by using the eventId as a token taxon when minting the NFT, then looking up on the ledger whether the receiving address has ever claimed / minted an NFT with that event id from your issuing account. (Basically using the ledger as your permanent state)

For milestone 3:

• Currently the function verifyOwnership checks if someone owns a specific NFT, but for verifying if someone has any token from the event, it’s unclear how someone would get the NFTokenID to pass into this function. You probably need something which looks up the details of the NFT (ex. Location, event code, etc.) and ensures that it was issued by the correct account.
• You can use the parseNFTokenID from xrpl.js to get a lot of that information from the NFT itself without a network call.
  Alternatively, if you can help us understand the user story for how someone who attended an event could look up the information they need to verify to someone else using this function that they actually own an NFT from an event. (We’re just a bit confused on the flow)

Additional nits / optional suggestions:

• Thanks for generating the docs, but they’re hard to read right now since you have to manually go through the html to read the text. It’d be very helpful to have that hosted somewhere. (This is a quick guide on how to set that up which might be helpful! https://codeburst.io/generate-docs-and-host-it-with-jsdoc-and-github-pages-113b9dae9acb)
• If you’re comfortable with it (not required) could you include the demo video showing how the tool works in the README? (We think it’d be helpful to show people the feature rather than just listing them - especially if there are barely-technical users)
• Nit: We’d recommend moving the constants in attendify.js into a file called constants.js or utils.js to make them easier to discover.
• Nit: In attendify.js (and maybe other files) you spell signature as signture which is a slight spelling mistake.
• Nit: For Flags use human readable versions from xrpl.js

We know this is a lot of feedback, so if you have any questions please let us know and we are happy to clarify / discuss what the best way to go about it could be!

[JustAnotherDevv]

Milestone 1
In my original implementation I wanted to generate new temporary wallet that would be used for minting and distribution of NFTs. My idea was that would make it harder to guess claim id for any particular event and it would give more agency to people creating those claim events because later on seed phrase to this new wallet could be given to them.
Looking at your feedback now I see that it was probably overengineered and I am already modifying my submission to include single account for minting and distribution of NFTs. claimableAddresses was the array storing these generated accounts that's why each minter was added there.

Milestone 2
After looking at documentation I don't see a way to query for getting just NFTs that were issued by specific account. Something similar to method account_nfts like
await client.request({ method: "nfts_by_issuer", account: address, })
Is it acceptable for the backend server to just store the list of participants adressess in a file/database?

Milestone 3
Is it acceptable that verifyOwnership function would take 2 additional args issuer and eventID then it would check whether or not user requesting verification has any NFT that was issued by issuer address? In this case the ID for specific NFT is no longer needed. I think that in the end the user could request verification for event ID that's stored in NFT Taxon.

Once all requested changes are completed and documented I will host the docs and demo video showcasing all of the features.

[JST5000]

Re: Milestone 2

1. There's this handy api you can use to get all NFTs with a given issuer :) - https://api.xrpldata.com/docs/static/index.html (Second command in the list).
2. Storing in a file/database seems fine to me :)

Re: Milestone 3

1. I think that makes sense. So if a user has an NFT, they have to look up the Issuer and NFTokenTaxon then they can provide those to the API in some way along with a signature, and it'll show they are in fact the owner of that NFT (is that right?)

[jonathanlei]

Announcement: We have a new addition to the process that will make it easier for reviewers and submitters to collaborate. Going forward, you will share your submission by opening a PR to new open source repo(s) under the XRPL Bounties github organization.

This will make it easier for reviewers and submitters to collaborate (comment on specific line of codes and request changes). It will also increase the publicity of your work, as the community will be able to find everything under XRPL Bounties.

What to do: Reply here with a link to your work-in-progress repo. If you've made enough progress for us to start requesting revisions, we will create an open source repo (under the XRPLBounties github org) for you to open PR(s) against.
The repo's default branch will start off empty, so that your PR will include your entire submission. This allows reviewers to easily comment directly on specific lines of code and collaborate with you more easily with PR reviews.

From now on, this process will be implemented for all bounties (except ones that are submitted to repos within XRPLF).
Thanks!

[jonathanlei]

The repository for this bounty has been created at: https://github.com/XRPLBounties/Proof-of-Attendance,
To be considered for the bounty, please create a PR against the main branch, thanks!

[JST5000]

(For context - the reason we're asking for that is so we can provide in-line comments on code & you can have more transparency into our approval process)

[JustAnotherDevv]

I have created PR to the repo with updated codebase. Will continue posting updates in there just like you requested.

[spicycheeto]

Resolved and did updates for all comments on Proof of Attendance submission #2. Awaiting further review and any additional comments / requirements.

[jonathanlei]

Milestone 1-3 has been claimed by @JustAnotherDevv, link to the API is here: https://github.com/XRPLBounties/Proof-of-Attendance. thanks for everyone's hard work, milestone 4 is still open.

[JustAnotherDevv]

7034

[JST5000]

Thanks for confirming your GitHub :)

[jiveyTO]

Minted 10 NFTs for attendees of our Toronto meetup in Feb

[JustAnotherDevv]

Awesome, happy to see first use case of my project. Will try to work on the official UI integration soon.