Discuss using FISSION Codes for Kickback

[bmann]

@hiddentao is iterating on the Kickback architecture -- see https://github.com/wearekickback/KIPs/blob/master/kips/kip-withdrawals.md

Discuss architecture and what common FISSION codes might be a fit to include, vs. which are application specific.

Via Twitter

[hiddentao]

Starting with Kickback we could generalize for events. The key point in the flow that would benefit from FISSION codes is when the person RSVPs to an event.

• RSVP to an event
  • Event already full (all spaces are gone)
  • Payment amount incorrect
  • Event already ended
  • Event not yet open for RSVP
  • You are ineligible to RSVP (for some other reason)

But we could further generalize these to the level of any group activity:

• Activity full (no spaces left)
• Payment for activity incorrect
• Activity already ended
• Activity not yet open for RSVP
• You cannot participate in this activity (e.g. due to a ban, not meeting some other criteria, etc)

[androolloyd]

Could we further generalize away from an activity?

Availability is a rather common need, ie: an event and a queue, are similar enough in their structures that an availability status would cover both.

[hiddentao]

We could call it a group?

• Group full (no spaces left)
• Payment for joining incorrect
• Group no longer active
• Group not yet open for joining
• You are forbidden from joining group