How to approach adding ability features to your app.

As you plan out the ability-related features your app will have, you'll find that some features are powered out-of-the-box by the Daylight API, while others are left to apps themselves to implement.

Features Powered by the Daylight API

Spam Reporting

If your user sees an ability that is not relevant to them or they perceive to be spammy, you can enable them to report it as spam to Daylight and our moderation team will review and moderate all reports for you.

Autotracking Completion

If a user completes an ability on-chain, we will track this for you and automatically remove that ability from that the wallet's abilities endpoint response for that user, as well as from any webhook notification. This insures the user sees relevant abilities and does not get a push notification for something they already did. We also track this for many off-chain abilities, but our coverage is not as complete there.

Showing Expired Abilities

When an ability has expired, we remove it from the default wallet's abilities response, and enable you to show users what their expired abilities are with the deadline = expired filter.

Features You May Want to Implement

Archiving, Hiding, or Marking Abilities as Completed

People may want to hide abilities they've completed, or that they're not interested in. Currently, Daylight doesn't track this granular level of interaction, but wallets may want to do something for their users.

The Daylight web app, for example, stores a list of ability UIDs that each user has hidden. Before displaying a list of abilities, the web app filters out those with a UID on that list.

Only Showing Token Requirements a User Qualifies For

When you request a wallet's abilities and an ability's requirement is hasTokenBalance, the requirements property of that ability will be all required tokens/communities of that ability, not just those the user qualifies for.

If you want to only show the required tokens that that user holds:

  • Fetch that wallet's communities
  • When rendering an ability, only show tokens that reference a community in that wallet's community list

This is not applicable to allowlist requirements.

Muting Communities

Some people may not want to see or be alerted by abilities of an entire community. The Daylight web app tackles this problem by storing a list of community contract addresses the user has muted, and filtering out abilities if they contain a requirement with a contract address on that list.

Advanced Display Filters

Daylight's wallet's abilities and community's abilities endpoints can be configured to return expired abilities, abilities in the far future, or abilities of a certain type. More granular filters can be implemented on the client side, for example:

  • In-memory type filtering
  • Filter by community
  • Filter by supplier
  • Show or hide hidden, archived, or completed abilities

Support for Multiple Wallets

Daylight's wallet's abilities endpoint return abilities for one wallet at a time. Wallets may choose to let users track multiple wallets at once.

On the Daylight web app, we chose to show abilities from multiple wallets in one single feed. These are some of the decisions we made to implement this:

  • When loading the feed, for each tracked wallet, we'd request a page of abilities.
  • As each page was returned, we'd concatenate and re-sort them all together and display them. (So if a user had N tracked wallets, we'd display up to N ⨉ 100 abilities on their feed.)
  • When the user scrolled down, if any of those tracked wallets had another page of abilities, we'd show a 'Load More' button.
  • Clicking 'Load More' would load a new page of abilities for every tracked wallet that had a second page.
  • We limited the people to adding up to 5 tracked wallets (in addition to the one owner wallet) to prevent them from hitting our API rate limits when browsing their abilities.