Document Notification API V2

[Foorack]

Old API: /auth/user/notifications

New API: /notifications

Objects and everything are COMPLETELY different. This is a complete rewrite.

[Foorack]

/notifications/<not_UUID>/respond

[Foorack]

Both V1 and V2 share not_ prefix, but are stored in completely separate tables/collections. They are not interchangeable.

[Rexios80]

Is there a new websocket endpoint as well?

[Foorack]

@Rexios80 No but it sends new kinds of objects down the websocket IIRC :-)

[Rexios80]

Are there equivalent objects just with different type strings?

[Foorack]

What? The Notification objects are completely different. In the Websocket it is indentified by a different type.

[Rexios80]

I meant equivalent as in they represent the same event. The answer should be yes.

[Rexios80]

So if I understood it correctly... only the group events are new in the websocket? Everything else is the same?

[Rexios80]

How do we want to handle this? I see a few options:

1. Rename the old APIs

   • Old notification APIs become: OldNotificaiton, OldNotificationsApi, etc.
   • New notification APIs are Notification, NoficationsApi, etc.

2. Name the new notifications APIs something else

   • Old notification APIs remain unchanged
   • New notification APIs are NotificationV2, NotificationsApiV2, etc.

3. Remove any references to the old APIs and name the new ones the same

If we do decide to keep the old notification APIs around, should we deprecate them?

Huh? Just because there is a V2 doesn't mean V1 is deprecated.

Notifications from both V1 and V2 share namespace (a.k.a not_), but a not_ from V1 must be sent to the V1 endpoint, and a V2 notification to a V2 endpoint. VRChat will likely run both in parallel for a very long time, so we definitively need to support both.