mirror of
https://github.com/superseriousbusiness/gotosocial.git
synced 2025-10-29 01:02:25 -05:00
754b7be9cf
~~Still WIP!~~ This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0. Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them. As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type. Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation). Migrations tested on both Postgres and SQLite. Co-authored-by: kim <grufwub@gmail.com> Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394 Co-authored-by: tobi <tobi.smethurst@protonmail.com> Co-committed-by: tobi <tobi.smethurst@protonmail.com> |
||
|---|---|---|
| .. | ||
| account.go | ||
| accountnote.go | ||
| accountsettings.go | ||
| accountstats.go | ||
| adminaction.go | ||
| advancedmigration.go | ||
| application.go | ||
| block.go | ||
| common.go | ||
| conversation.go | ||
| domainallow.go | ||
| domainblock.go | ||
| domainpermission.go | ||
| domainpermissiondraft.go | ||
| domainpermissionexclude.go | ||
| domainpermissionsubscription.go | ||
| emaildomainblock.go | ||
| emoji.go | ||
| emojicategory.go | ||
| filter.go | ||
| follow.go | ||
| followrequest.go | ||
| headerfilter.go | ||
| instance.go | ||
| interaction.go | ||
| interactionpolicy.go | ||
| list.go | ||
| marker.go | ||
| mediaattachment.go | ||
| mention.go | ||
| move.go | ||
| notification.go | ||
| poll.go | ||
| README.md | ||
| report.go | ||
| routersession.go | ||
| rule.go | ||
| scheduledstatus.go | ||
| sinbinstatus.go | ||
| status.go | ||
| statusbookmark.go | ||
| statusedit.go | ||
| statusfave.go | ||
| statusmute.go | ||
| tag.go | ||
| thread.go | ||
| threadmute.go | ||
| token.go | ||
| tombstone.go | ||
| user.go | ||
| usermute.go | ||
| vapidkeypair.go | ||
| webpushsubscription.go | ||
| workertask.go | ||
A note on when we should set data structures linked to objects in the database to use the
bun nullzero tag -- this should only be done if the member type is a pointer, or if the
this primitive type is literally invalid with an empty value (e.g. media IDs which when
empty signifies a null database value, compared to say an account note which when empty
could mean either an empty note OR null database value).
Obviously it is a little more complex than this in practice, but keep it in mind!