You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to leave some thoughts I've had while building the SDK that may help to inform the development of the next iteration of the API.
Does it make sense to prescribe one notification to be push and another to be activity? As an open protocol I'd argue that they are all notification and it should be up to developers building on our platform to make that distinction in their frontend by choosing which are quickly visible and through a setting panel that allows users to turn on and off emails for specific notifications.
The leaderboard endpoint is a departure from the pattern put in place by bounties, fulfillments, etc where a single entity can be retrieved by drilling down /{entity}/{id} or a list could be retrieved via some query to the /{entity} endpoint. I believe that leaderboard should be generalized and accessible via the /user endpoint and customizable using queries.
For continuity sake, I think the categories, skills, tokens, and languages should also follow the /{entity}/{id} || /{entity} pattern.
The comments endpoint should be decoupled from a bounty like fulfillments. It may be useful to retrieve all of a specific user's comments.
How are we going to seamlessly integrate STB2 where bounties are identified by addresses instead of ids? It doesn't make sense to me to require users who want to know about a bounty at 0x123...456 to first ping our API to determine that bounties id before calling the /bounty endpoint.
I'll add more to this thread as they come up!
The text was updated successfully, but these errors were encountered:
After talking with @villanuevawill, we think it makes sense to keep the current comments endpoints and just add a general read-only endpoint to query a user's comments.
I want to leave some thoughts I've had while building the SDK that may help to inform the development of the next iteration of the API.
Does it make sense to prescribe one notification to be
push
and another to beactivity
? As an open protocol I'd argue that they are allnotification
and it should be up to developers building on our platform to make that distinction in their frontend by choosing which are quickly visible and through a setting panel that allows users to turn on and off emails for specific notifications.The leaderboard endpoint is a departure from the pattern put in place by bounties, fulfillments, etc where a single entity can be retrieved by drilling down/{entity}/{id}
or a list could be retrieved via some query to the/{entity}
endpoint. I believe that leaderboard should be generalized and accessible via the/user
endpoint and customizable using queries.For continuity sake, I think the
categories
,skills
,tokens
, andlanguages
should also follow the/{entity}/{id}
||/{entity}
pattern.The
comments
endpoint should be decoupled from abounty
likefulfillments
. It may be useful to retrieve all of a specific user's comments.How are we going to seamlessly integrate STB2 where bounties are identified by addresses instead of
id
s? It doesn't make sense to me to require users who want to know about a bounty at0x123...456
to first ping our API to determine that bountiesid
before calling the/bounty
endpoint.I'll add more to this thread as they come up!
The text was updated successfully, but these errors were encountered: