2023-08-09 19:14:33 +02:00
|
|
|
// GoToSocial
|
|
|
|
|
// Copyright (C) GoToSocial Authors admin@gotosocial.org
|
|
|
|
|
// SPDX-License-Identifier: AGPL-3.0-or-later
|
|
|
|
|
//
|
|
|
|
|
// This program is free software: you can redistribute it and/or modify
|
|
|
|
|
// it under the terms of the GNU Affero General Public License as published by
|
|
|
|
|
// the Free Software Foundation, either version 3 of the License, or
|
|
|
|
|
// (at your option) any later version.
|
|
|
|
|
//
|
|
|
|
|
// This program is distributed in the hope that it will be useful,
|
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
// GNU Affero General Public License for more details.
|
|
|
|
|
//
|
|
|
|
|
// You should have received a copy of the GNU Affero General Public License
|
|
|
|
|
// along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
|
|
package workers
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"context"
|
2024-04-26 13:50:46 +01:00
|
|
|
"errors"
|
2024-10-08 10:51:13 +02:00
|
|
|
"net/url"
|
2024-08-24 11:49:37 +02:00
|
|
|
"time"
|
2023-08-09 19:14:33 +02:00
|
|
|
|
2025-04-26 15:34:10 +02:00
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/ap"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/db"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/federation/dereferencing"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/gtscontext"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/id"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/uris"
|
2025-07-29 09:23:20 +02:00
|
|
|
"codeberg.org/gruf/go-kv/v2"
|
2024-02-09 15:24:49 +01:00
|
|
|
|
2025-04-26 15:34:10 +02:00
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/gtserror"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/gtsmodel"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/log"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/messages"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/processing/account"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/processing/common"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/state"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/util"
|
2023-08-09 19:14:33 +02:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
// fediAPI wraps processing functions
|
|
|
|
|
// specifically for messages originating
|
|
|
|
|
// from the federation/ActivityPub API.
|
|
|
|
|
type fediAPI struct {
|
2024-03-13 13:53:29 +01:00
|
|
|
state *state.State
|
2024-05-02 14:43:00 +02:00
|
|
|
surface *Surface
|
2024-03-13 13:53:29 +01:00
|
|
|
federate *federate
|
|
|
|
|
account *account.Processor
|
2024-08-24 11:49:37 +02:00
|
|
|
common *common.Processor
|
2024-04-26 13:50:46 +01:00
|
|
|
utils *utils
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *Processor) ProcessFromFediAPI(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2023-08-09 19:14:33 +02:00
|
|
|
// Allocate new log fields slice
|
|
|
|
|
fields := make([]kv.Field, 3, 5)
|
|
|
|
|
fields[0] = kv.Field{"activityType", fMsg.APActivityType}
|
|
|
|
|
fields[1] = kv.Field{"objectType", fMsg.APObjectType}
|
2024-04-26 13:50:46 +01:00
|
|
|
fields[2] = kv.Field{"toAccount", fMsg.Receiving.Username}
|
2023-08-09 19:14:33 +02:00
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
if fMsg.APIRI != nil {
|
2023-08-09 19:14:33 +02:00
|
|
|
// An IRI was supplied, append to log
|
|
|
|
|
fields = append(fields, kv.Field{
|
2024-04-26 13:50:46 +01:00
|
|
|
"iri", fMsg.APIRI,
|
2023-08-09 19:14:33 +02:00
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Include GTSModel in logs if appropriate.
|
|
|
|
|
if fMsg.GTSModel != nil &&
|
2024-09-20 13:30:33 +00:00
|
|
|
log.Level() >= log.DEBUG {
|
2023-08-09 19:14:33 +02:00
|
|
|
fields = append(fields, kv.Field{
|
|
|
|
|
"model", fMsg.GTSModel,
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
l := log.WithContext(ctx).WithFields(fields...)
|
|
|
|
|
l.Info("processing from fedi API")
|
|
|
|
|
|
|
|
|
|
switch fMsg.APActivityType {
|
|
|
|
|
|
|
|
|
|
// CREATE SOMETHING
|
|
|
|
|
case ap.ActivityCreate:
|
|
|
|
|
switch fMsg.APObjectType {
|
|
|
|
|
|
|
|
|
|
// CREATE NOTE/STATUS
|
|
|
|
|
case ap.ObjectNote:
|
|
|
|
|
return p.fediAPI.CreateStatus(ctx, fMsg)
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// REQUEST TO REPLY TO A STATUS
|
|
|
|
|
case ap.ActivityReplyRequest:
|
|
|
|
|
return p.fediAPI.CreateReplyRequest(ctx, fMsg)
|
|
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
// CREATE FOLLOW (request)
|
|
|
|
|
case ap.ActivityFollow:
|
|
|
|
|
return p.fediAPI.CreateFollowReq(ctx, fMsg)
|
|
|
|
|
|
|
|
|
|
// CREATE LIKE/FAVE
|
|
|
|
|
case ap.ActivityLike:
|
|
|
|
|
return p.fediAPI.CreateLike(ctx, fMsg)
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// REQUEST TO LIKE A STATUS
|
|
|
|
|
case ap.ActivityLikeRequest:
|
|
|
|
|
return p.fediAPI.CreateLikeRequest(ctx, fMsg)
|
|
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
// CREATE ANNOUNCE/BOOST
|
|
|
|
|
case ap.ActivityAnnounce:
|
|
|
|
|
return p.fediAPI.CreateAnnounce(ctx, fMsg)
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// REQUEST TO BOOST A STATUS
|
|
|
|
|
case ap.ActivityAnnounceRequest:
|
|
|
|
|
return p.fediAPI.CreateAnnounceRequest(ctx, fMsg)
|
|
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
// CREATE BLOCK
|
|
|
|
|
case ap.ActivityBlock:
|
|
|
|
|
return p.fediAPI.CreateBlock(ctx, fMsg)
|
|
|
|
|
|
|
|
|
|
// CREATE FLAG/REPORT
|
|
|
|
|
case ap.ActivityFlag:
|
|
|
|
|
return p.fediAPI.CreateFlag(ctx, fMsg)
|
2023-11-08 14:32:17 +00:00
|
|
|
|
|
|
|
|
// CREATE QUESTION
|
|
|
|
|
case ap.ActivityQuestion:
|
|
|
|
|
return p.fediAPI.CreatePollVote(ctx, fMsg)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// UPDATE SOMETHING
|
|
|
|
|
case ap.ActivityUpdate:
|
2024-04-16 13:10:13 +02:00
|
|
|
switch fMsg.APObjectType {
|
2023-08-09 19:14:33 +02:00
|
|
|
|
2023-10-04 13:09:42 +01:00
|
|
|
// UPDATE NOTE/STATUS
|
|
|
|
|
case ap.ObjectNote:
|
|
|
|
|
return p.fediAPI.UpdateStatus(ctx, fMsg)
|
|
|
|
|
|
2024-06-06 15:43:25 +02:00
|
|
|
// UPDATE ACCOUNT
|
|
|
|
|
case ap.ActorPerson:
|
2023-08-09 19:14:33 +02:00
|
|
|
return p.fediAPI.UpdateAccount(ctx, fMsg)
|
2025-02-20 10:13:07 +00:00
|
|
|
|
|
|
|
|
// UPDATE QUESTION
|
|
|
|
|
case ap.ActivityQuestion:
|
|
|
|
|
return p.fediAPI.UpdatePollVote(ctx, fMsg)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
2024-04-16 13:10:13 +02:00
|
|
|
// ACCEPT SOMETHING
|
|
|
|
|
case ap.ActivityAccept:
|
2024-07-26 12:04:28 +02:00
|
|
|
switch fMsg.APObjectType {
|
2024-04-16 13:10:13 +02:00
|
|
|
|
2024-07-26 12:04:28 +02:00
|
|
|
// ACCEPT (pending) FOLLOW
|
2024-04-16 13:10:13 +02:00
|
|
|
case ap.ActivityFollow:
|
|
|
|
|
return p.fediAPI.AcceptFollow(ctx, fMsg)
|
2024-07-26 12:04:28 +02:00
|
|
|
|
|
|
|
|
// ACCEPT (pending) LIKE
|
|
|
|
|
case ap.ActivityLike:
|
|
|
|
|
return p.fediAPI.AcceptLike(ctx, fMsg)
|
|
|
|
|
|
|
|
|
|
// ACCEPT (pending) REPLY
|
|
|
|
|
case ap.ObjectNote:
|
|
|
|
|
return p.fediAPI.AcceptReply(ctx, fMsg)
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// ACCEPT (pending) POLITE REPLY REQUEST
|
|
|
|
|
case ap.ActivityReplyRequest:
|
|
|
|
|
return p.fediAPI.AcceptPoliteReplyRequest(ctx, fMsg)
|
|
|
|
|
|
2024-07-26 12:04:28 +02:00
|
|
|
// ACCEPT (pending) ANNOUNCE
|
|
|
|
|
case ap.ActivityAnnounce:
|
|
|
|
|
return p.fediAPI.AcceptAnnounce(ctx, fMsg)
|
2024-10-08 10:51:13 +02:00
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// ACCEPT (remote) IMPOLITE REPLY or ANNOUNCE
|
2024-10-08 10:51:13 +02:00
|
|
|
case ap.ObjectUnknown:
|
|
|
|
|
return p.fediAPI.AcceptRemoteStatus(ctx, fMsg)
|
2024-04-16 13:10:13 +02:00
|
|
|
}
|
|
|
|
|
|
2024-09-10 14:34:49 +02:00
|
|
|
// REJECT SOMETHING
|
|
|
|
|
case ap.ActivityReject:
|
|
|
|
|
switch fMsg.APObjectType {
|
|
|
|
|
|
|
|
|
|
// REJECT LIKE
|
|
|
|
|
case ap.ActivityLike:
|
|
|
|
|
return p.fediAPI.RejectLike(ctx, fMsg)
|
|
|
|
|
|
|
|
|
|
// REJECT NOTE/STATUS (ie., reject a reply)
|
|
|
|
|
case ap.ObjectNote:
|
|
|
|
|
return p.fediAPI.RejectReply(ctx, fMsg)
|
|
|
|
|
|
|
|
|
|
// REJECT BOOST
|
|
|
|
|
case ap.ActivityAnnounce:
|
|
|
|
|
return p.fediAPI.RejectAnnounce(ctx, fMsg)
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
// DELETE SOMETHING
|
|
|
|
|
case ap.ActivityDelete:
|
|
|
|
|
switch fMsg.APObjectType {
|
|
|
|
|
|
|
|
|
|
// DELETE NOTE/STATUS
|
|
|
|
|
case ap.ObjectNote:
|
|
|
|
|
return p.fediAPI.DeleteStatus(ctx, fMsg)
|
|
|
|
|
|
2024-06-06 15:43:25 +02:00
|
|
|
// DELETE ACCOUNT
|
|
|
|
|
case ap.ActorPerson:
|
2023-08-09 19:14:33 +02:00
|
|
|
return p.fediAPI.DeleteAccount(ctx, fMsg)
|
|
|
|
|
}
|
2024-03-12 15:34:08 +01:00
|
|
|
|
|
|
|
|
// MOVE SOMETHING
|
|
|
|
|
case ap.ActivityMove:
|
|
|
|
|
|
2024-06-06 15:43:25 +02:00
|
|
|
// MOVE ACCOUNT
|
2024-03-12 15:34:08 +01:00
|
|
|
// fromfediapi_move.go.
|
2024-06-06 15:43:25 +02:00
|
|
|
if fMsg.APObjectType == ap.ActorPerson {
|
2024-03-12 15:34:08 +01:00
|
|
|
return p.fediAPI.MoveAccount(ctx, fMsg)
|
|
|
|
|
}
|
2025-01-24 16:36:34 +00:00
|
|
|
|
|
|
|
|
// UNDO SOMETHING
|
|
|
|
|
case ap.ActivityUndo:
|
|
|
|
|
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
switch fMsg.APObjectType {
|
|
|
|
|
// UNDO FOLLOW
|
|
|
|
|
case ap.ActivityFollow:
|
|
|
|
|
return p.fediAPI.UndoFollow(ctx, fMsg)
|
|
|
|
|
|
|
|
|
|
// UNDO BLOCK
|
|
|
|
|
case ap.ActivityBlock:
|
|
|
|
|
return p.fediAPI.UndoBlock(ctx, fMsg)
|
|
|
|
|
|
2025-01-24 16:36:34 +00:00
|
|
|
// UNDO ANNOUNCE
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
case ap.ActivityAnnounce:
|
2025-01-24 16:36:34 +00:00
|
|
|
return p.fediAPI.UndoAnnounce(ctx, fMsg)
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
|
|
|
|
|
// UNDO LIKE
|
|
|
|
|
case ap.ActivityLike:
|
|
|
|
|
return p.fediAPI.UndoFave(ctx, fMsg)
|
2025-01-24 16:36:34 +00:00
|
|
|
}
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
2023-11-04 20:21:20 +00:00
|
|
|
return gtserror.Newf("unhandled: %s %s", fMsg.APActivityType, fMsg.APObjectType)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// CreateStatus handles the creation of a status/post sent as a Create message.
|
|
|
|
|
// It is also capable of handling impolite reply requests to local + remote statuses,
|
|
|
|
|
// ie., replies sent directly without doing the ReplyRequest process first.
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *fediAPI) CreateStatus(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2023-08-09 19:14:33 +02:00
|
|
|
var (
|
2023-12-01 10:53:53 +00:00
|
|
|
status *gtsmodel.Status
|
|
|
|
|
statusable ap.Statusable
|
|
|
|
|
err error
|
2023-08-09 19:14:33 +02:00
|
|
|
)
|
|
|
|
|
|
2023-12-01 10:53:53 +00:00
|
|
|
var ok bool
|
|
|
|
|
|
|
|
|
|
switch {
|
2024-04-26 13:50:46 +01:00
|
|
|
case fMsg.APObject != nil:
|
2023-12-01 10:53:53 +00:00
|
|
|
// A model was provided, extract this from message.
|
2024-04-26 13:50:46 +01:00
|
|
|
statusable, ok = fMsg.APObject.(ap.Statusable)
|
2023-12-01 10:53:53 +00:00
|
|
|
if !ok {
|
2024-04-26 13:50:46 +01:00
|
|
|
return gtserror.Newf("cannot cast %T -> ap.Statusable", fMsg.APObject)
|
2023-12-01 10:53:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Create bare-bones model to pass
|
|
|
|
|
// into RefreshStatus(), which it will
|
|
|
|
|
// further populate and insert as new.
|
|
|
|
|
bareStatus := new(gtsmodel.Status)
|
|
|
|
|
bareStatus.Local = util.Ptr(false)
|
|
|
|
|
bareStatus.URI = ap.GetJSONLDId(statusable).String()
|
|
|
|
|
|
|
|
|
|
// Call RefreshStatus() to parse and process the provided
|
|
|
|
|
// statusable model, which it will use to further flesh out
|
|
|
|
|
// the bare bones model and insert it into the database.
|
|
|
|
|
status, statusable, err = p.federate.RefreshStatus(ctx,
|
2024-04-26 13:50:46 +01:00
|
|
|
fMsg.Receiving.Username,
|
2023-12-01 10:53:53 +00:00
|
|
|
bareStatus,
|
|
|
|
|
statusable,
|
2024-02-09 15:24:49 +01:00
|
|
|
// Force refresh within 5min window.
|
|
|
|
|
dereferencing.Fresh,
|
2023-12-01 10:53:53 +00:00
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return gtserror.Newf("error processing new status %s: %w", bareStatus.URI, err)
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
case fMsg.APIRI != nil:
|
2023-11-04 20:21:20 +00:00
|
|
|
// Model was not set, deref with IRI (this is a forward).
|
2023-08-09 19:14:33 +02:00
|
|
|
// This will also cause the status to be inserted into the db.
|
2023-12-01 10:53:53 +00:00
|
|
|
status, statusable, err = p.federate.GetStatusByURI(ctx,
|
2024-04-26 13:50:46 +01:00
|
|
|
fMsg.Receiving.Username,
|
|
|
|
|
fMsg.APIRI,
|
2023-12-01 10:53:53 +00:00
|
|
|
)
|
|
|
|
|
if err != nil {
|
2024-04-26 13:50:46 +01:00
|
|
|
return gtserror.Newf("error dereferencing forwarded status %s: %w", fMsg.APIRI, err)
|
2023-12-01 10:53:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
return gtserror.New("neither APObjectModel nor APIri set")
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
2023-12-01 10:53:53 +00:00
|
|
|
if statusable == nil {
|
|
|
|
|
// Another thread beat us to
|
|
|
|
|
// creating this status! Return
|
|
|
|
|
// here and let the other thread
|
|
|
|
|
// handle timelining + notifying.
|
|
|
|
|
return nil
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
2024-07-26 12:04:28 +02:00
|
|
|
// If pending approval is true then
|
|
|
|
|
// status must reply to a LOCAL status
|
|
|
|
|
// that requires approval for the reply.
|
2024-08-24 11:49:37 +02:00
|
|
|
pendingApproval := util.PtrOrZero(status.PendingApproval)
|
2024-07-26 12:04:28 +02:00
|
|
|
|
|
|
|
|
switch {
|
|
|
|
|
case pendingApproval && !status.PreApproved:
|
|
|
|
|
// If approval is required and status isn't
|
|
|
|
|
// preapproved, then just notify the account
|
|
|
|
|
// that's being interacted with: they can
|
|
|
|
|
// approve or deny the interaction later.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
if err := p.utils.impoliteReplyRequest(ctx, status); err != nil {
|
2024-08-24 11:49:37 +02:00
|
|
|
return gtserror.Newf("error pending reply: %w", err)
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Return early.
|
|
|
|
|
return nil
|
|
|
|
|
|
|
|
|
|
case pendingApproval && status.PreApproved:
|
|
|
|
|
// If approval is required and status is
|
|
|
|
|
// preapproved, that means this is a reply
|
|
|
|
|
// to one of our statuses with permission
|
|
|
|
|
// that matched on a following/followers
|
|
|
|
|
// collection. Do the Accept immediately and
|
|
|
|
|
// then process everything else as normal.
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// Store an already-accepted
|
|
|
|
|
// impolite interaction request.
|
|
|
|
|
requestID := id.NewULID()
|
2024-08-24 11:49:37 +02:00
|
|
|
approval := >smodel.InteractionRequest{
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
ID: requestID,
|
|
|
|
|
TargetStatusID: status.InReplyToID,
|
|
|
|
|
TargetAccountID: status.InReplyToAccountID,
|
|
|
|
|
TargetAccount: status.InReplyToAccount,
|
|
|
|
|
InteractingAccountID: status.AccountID,
|
|
|
|
|
InteractingAccount: status.Account,
|
|
|
|
|
InteractionRequestURI: gtsmodel.ForwardCompatibleInteractionRequestURI(status.URI, gtsmodel.ReplyRequestSuffix),
|
|
|
|
|
InteractionURI: status.URI,
|
|
|
|
|
InteractionType: gtsmodel.InteractionReply,
|
|
|
|
|
Polite: util.Ptr(false),
|
|
|
|
|
Reply: status,
|
|
|
|
|
ResponseURI: uris.GenerateURIForAccept(status.InReplyToAccount.Username, requestID),
|
|
|
|
|
AuthorizationURI: uris.GenerateURIForAuthorization(status.InReplyToAccount.Username, requestID),
|
|
|
|
|
AcceptedAt: time.Now(),
|
2024-08-24 11:49:37 +02:00
|
|
|
}
|
2024-08-24 14:17:55 +02:00
|
|
|
if err := p.state.DB.PutInteractionRequest(ctx, approval); err != nil {
|
|
|
|
|
return gtserror.Newf("db error putting pre-approved interaction request: %w", err)
|
|
|
|
|
}
|
2024-08-24 11:49:37 +02:00
|
|
|
|
|
|
|
|
// Mark the status as now approved.
|
|
|
|
|
status.PendingApproval = util.Ptr(false)
|
|
|
|
|
status.PreApproved = false
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
status.ApprovedByURI = approval.AuthorizationURI
|
2024-08-24 11:49:37 +02:00
|
|
|
if err := p.state.DB.UpdateStatus(
|
|
|
|
|
ctx,
|
|
|
|
|
status,
|
|
|
|
|
"pending_approval",
|
|
|
|
|
"approved_by_uri",
|
|
|
|
|
); err != nil {
|
|
|
|
|
return gtserror.Newf("db error updating status: %w", err)
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Send out the approval as Accept.
|
|
|
|
|
if err := p.federate.AcceptInteraction(ctx, approval); err != nil {
|
|
|
|
|
return gtserror.Newf("error federating pre-approval of reply: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Don't return, just continue as normal.
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-16 13:10:13 +02:00
|
|
|
// Update stats for the remote account.
|
2024-04-26 13:50:46 +01:00
|
|
|
if err := p.utils.incrementStatusesCount(ctx, fMsg.Requesting, status); err != nil {
|
2024-04-16 13:10:13 +02:00
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
2024-08-24 11:49:37 +02:00
|
|
|
if err := p.surface.timelineAndNotifyStatus(ctx, status); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error timelining and notifying status: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
if status.InReplyToID != "" {
|
2023-11-04 20:21:20 +00:00
|
|
|
// Interaction counts changed on the replied status; uncache the
|
|
|
|
|
// prepared version from all timelines. The status dereferencer
|
|
|
|
|
// functions will ensure necessary ancestors exist before this point.
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
p.surface.invalidateStatusFromTimelines(status.InReplyToID)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
2023-11-08 14:32:17 +00:00
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// CreateReplyRequest handles a polite ReplyRequest.
|
|
|
|
|
// This is distinct from CreateStatus, which is capable
|
|
|
|
|
// of handling both "normal" top-level status creation,
|
|
|
|
|
// in addition to *impolite* reply requests.
|
|
|
|
|
func (p *fediAPI) CreateReplyRequest(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
// Extract the ap model Statusable
|
|
|
|
|
// set by the federating db.
|
|
|
|
|
statusable, ok := fMsg.APObject.(ap.Statusable)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("cannot cast %T -> ap.Statusable", fMsg.APObject)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Call RefreshStatus to parse and process the
|
|
|
|
|
// statusable. This will also check permissions.
|
|
|
|
|
replyURI := ap.GetJSONLDId(statusable).String()
|
|
|
|
|
reply, _, err := p.federate.RefreshStatus(ctx,
|
|
|
|
|
fMsg.Receiving.Username,
|
|
|
|
|
>smodel.Status{
|
|
|
|
|
URI: replyURI,
|
|
|
|
|
Local: util.Ptr(false),
|
|
|
|
|
},
|
|
|
|
|
statusable,
|
|
|
|
|
// Force refresh within 5min window.
|
|
|
|
|
dereferencing.Fresh,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
switch {
|
|
|
|
|
case err == nil:
|
|
|
|
|
// All fine.
|
|
|
|
|
|
|
|
|
|
case gtserror.IsNotPermitted(err):
|
|
|
|
|
// Reply is straight up not permitted by
|
|
|
|
|
// the interaction policy of the status
|
|
|
|
|
// it's replying to. Nothing more to do.
|
|
|
|
|
log.Debugf(ctx,
|
|
|
|
|
"dropping unpermitted ReplyRequest with instrument %s",
|
|
|
|
|
replyURI,
|
|
|
|
|
)
|
|
|
|
|
return nil
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
// There's some real error.
|
|
|
|
|
return gtserror.Newf(
|
|
|
|
|
"error processing ReplyRequest with instrument %s: %w",
|
|
|
|
|
replyURI, err,
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// The reply is permitted. Check if we
|
|
|
|
|
// should send out an Accept immediately.
|
|
|
|
|
manualApproval := *reply.PendingApproval && !reply.PreApproved
|
|
|
|
|
if manualApproval {
|
|
|
|
|
// The reply requires manual approval.
|
|
|
|
|
//
|
|
|
|
|
// Just notify target account about
|
|
|
|
|
// the requested interaction.
|
|
|
|
|
if err := p.surface.notifyPendingReply(ctx, reply); err != nil {
|
|
|
|
|
return gtserror.Newf("error notifying pending reply: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// The reply is automatically approved,
|
|
|
|
|
// handle side effects of this.
|
|
|
|
|
req, ok := fMsg.GTSModel.(*gtsmodel.InteractionRequest)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.InteractionRequest", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Mark the request as accepted.
|
|
|
|
|
req.AcceptedAt = time.Now()
|
|
|
|
|
req.ResponseURI = uris.GenerateURIForAccept(
|
|
|
|
|
req.TargetAccount.Username, req.ID,
|
|
|
|
|
)
|
|
|
|
|
req.AuthorizationURI = uris.GenerateURIForAuthorization(
|
|
|
|
|
req.TargetAccount.Username, req.ID,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
// Update in the db.
|
|
|
|
|
if err := p.state.DB.UpdateInteractionRequest(
|
|
|
|
|
ctx,
|
|
|
|
|
req,
|
|
|
|
|
"accepted_at",
|
|
|
|
|
"response_uri",
|
|
|
|
|
"authorization_uri",
|
|
|
|
|
); err != nil {
|
|
|
|
|
return gtserror.Newf("db error updating interaction request: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Send out the accept.
|
|
|
|
|
if err := p.federate.AcceptInteraction(ctx, req); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error federating accept: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Update stats for the replying account.
|
|
|
|
|
if err := p.utils.incrementStatusesCount(ctx, fMsg.Requesting, reply); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Timeline the reply + notify recipient(s).
|
|
|
|
|
if err := p.surface.timelineAndNotifyStatus(ctx, reply); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error timelining and notifying status: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Interaction counts changed on the replied status;
|
|
|
|
|
// uncache the prepared version from all timelines.
|
|
|
|
|
p.surface.invalidateStatusFromTimelines(reply.InReplyToID)
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *fediAPI) CreatePollVote(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2023-11-08 14:32:17 +00:00
|
|
|
// Cast poll vote type from the worker message.
|
|
|
|
|
vote, ok := fMsg.GTSModel.(*gtsmodel.PollVote)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("cannot cast %T -> *gtsmodel.PollVote", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
2025-02-20 10:13:07 +00:00
|
|
|
// Insert the new poll vote in the database, note this
|
|
|
|
|
// will handle updating votes on the poll model itself.
|
2023-11-08 14:32:17 +00:00
|
|
|
if err := p.state.DB.PutPollVote(ctx, vote); err != nil {
|
|
|
|
|
return gtserror.Newf("error inserting poll vote in db: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Ensure the poll vote is fully populated at this point.
|
|
|
|
|
if err := p.state.DB.PopulatePollVote(ctx, vote); err != nil {
|
|
|
|
|
return gtserror.Newf("error populating poll vote from db: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Ensure the poll on the vote is fully populated to get origin status.
|
|
|
|
|
if err := p.state.DB.PopulatePoll(ctx, vote.Poll); err != nil {
|
|
|
|
|
return gtserror.Newf("error populating poll from db: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Get the origin status,
|
|
|
|
|
// (also set the poll on it).
|
|
|
|
|
status := vote.Poll.Status
|
|
|
|
|
status.Poll = vote.Poll
|
|
|
|
|
|
|
|
|
|
if *status.Local {
|
2025-02-20 10:13:07 +00:00
|
|
|
// Before federating it, increment the poll vote
|
|
|
|
|
// and voter counts, *only on our local copy*.
|
|
|
|
|
status.Poll.IncrementVotes(vote.Choices, true)
|
|
|
|
|
|
|
|
|
|
// These were poll votes in a local status, we need to
|
|
|
|
|
// federate the updated status model with latest vote counts.
|
|
|
|
|
if err := p.federate.UpdateStatus(ctx, status); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error federating status update: %v", err)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Interaction counts changed, uncache from timelines.
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
p.surface.invalidateStatusFromTimelines(status.ID)
|
2025-02-20 10:13:07 +00:00
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
2023-11-08 22:37:35 +00:00
|
|
|
|
2025-02-20 10:13:07 +00:00
|
|
|
func (p *fediAPI) UpdatePollVote(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
// Cast poll vote type from the worker message.
|
|
|
|
|
vote, ok := fMsg.GTSModel.(*gtsmodel.PollVote)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("cannot cast %T -> *gtsmodel.PollVote", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Update poll vote model (specifically only choices) in the database.
|
|
|
|
|
if err := p.state.DB.UpdatePollVote(ctx, vote, "choices"); err != nil {
|
|
|
|
|
return gtserror.Newf("error updating poll vote in db: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Update the vote counts on the poll model itself. These will have
|
|
|
|
|
// been updated by message pusher as we can't know which were new.
|
|
|
|
|
if err := p.state.DB.UpdatePoll(ctx, vote.Poll, "votes"); err != nil {
|
|
|
|
|
return gtserror.Newf("error updating poll in db: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Get the origin status.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
reply := vote.Poll.Status
|
2025-02-20 10:13:07 +00:00
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
if *reply.Local {
|
2023-11-08 14:32:17 +00:00
|
|
|
// These were poll votes in a local status, we need to
|
|
|
|
|
// federate the updated status model with latest vote counts.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
if err := p.federate.UpdateStatus(ctx, reply); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error federating status update: %v", err)
|
|
|
|
|
}
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
2025-02-20 10:13:07 +00:00
|
|
|
// Interaction counts changed, uncache from timelines.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
p.surface.invalidateStatusFromTimelines(reply.ID)
|
2024-08-24 11:49:37 +02:00
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *fediAPI) CreateFollowReq(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2023-08-09 19:14:33 +02:00
|
|
|
followRequest, ok := fMsg.GTSModel.(*gtsmodel.FollowRequest)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.FollowRequest", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-11 11:05:49 +02:00
|
|
|
if err := p.state.DB.PopulateFollowRequest(ctx, followRequest); err != nil {
|
|
|
|
|
return gtserror.Newf("error populating follow request: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
if *followRequest.TargetAccount.Locked {
|
2024-04-16 13:10:13 +02:00
|
|
|
// Local account is locked: just notify the follow request.
|
2023-08-09 19:14:33 +02:00
|
|
|
if err := p.surface.notifyFollowRequest(ctx, followRequest); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error notifying follow request: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
2024-04-16 13:10:13 +02:00
|
|
|
|
|
|
|
|
// And update stats for the local account.
|
2024-04-26 13:50:46 +01:00
|
|
|
if err := p.utils.incrementFollowRequestsCount(ctx, fMsg.Receiving); err != nil {
|
2024-04-16 13:10:13 +02:00
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-16 13:10:13 +02:00
|
|
|
// Local account is not locked:
|
2023-08-09 19:14:33 +02:00
|
|
|
// Automatically accept the follow request
|
|
|
|
|
// and notify about the new follower.
|
|
|
|
|
follow, err := p.state.DB.AcceptFollowRequest(
|
|
|
|
|
ctx,
|
|
|
|
|
followRequest.AccountID,
|
|
|
|
|
followRequest.TargetAccountID,
|
|
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return gtserror.Newf("error accepting follow request: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-16 13:10:13 +02:00
|
|
|
// Update stats for the local account.
|
2024-04-26 13:50:46 +01:00
|
|
|
if err := p.utils.incrementFollowersCount(ctx, fMsg.Receiving); err != nil {
|
2024-04-16 13:10:13 +02:00
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Update stats for the remote account.
|
2024-04-26 13:50:46 +01:00
|
|
|
if err := p.utils.incrementFollowingCount(ctx, fMsg.Requesting); err != nil {
|
2024-04-16 13:10:13 +02:00
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
if err := p.federate.AcceptFollow(ctx, follow); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error federating follow request accept: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if err := p.surface.notifyFollow(ctx, follow); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error notifying follow: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// CreateLike handles an impolite Like, ie., a Like sent directly.
|
|
|
|
|
// This is different from the CreateLikeRequest function, which handles polite LikeRequests.
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *fediAPI) CreateLike(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2023-08-09 19:14:33 +02:00
|
|
|
fave, ok := fMsg.GTSModel.(*gtsmodel.StatusFave)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.StatusFave", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-25 16:04:53 +02:00
|
|
|
// Ensure fave populated.
|
|
|
|
|
if err := p.state.DB.PopulateStatusFave(ctx, fave); err != nil {
|
|
|
|
|
return gtserror.Newf("error populating status fave: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
2024-07-26 12:04:28 +02:00
|
|
|
// If pending approval is true then
|
|
|
|
|
// fave must target a LOCAL status
|
|
|
|
|
// that requires approval for the fave.
|
2024-08-24 11:49:37 +02:00
|
|
|
pendingApproval := util.PtrOrZero(fave.PendingApproval)
|
2024-07-26 12:04:28 +02:00
|
|
|
|
|
|
|
|
switch {
|
|
|
|
|
case pendingApproval && !fave.PreApproved:
|
|
|
|
|
// If approval is required and fave isn't
|
|
|
|
|
// preapproved, then just notify the account
|
|
|
|
|
// that's being interacted with: they can
|
|
|
|
|
// approve or deny the interaction later.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
if err := p.utils.impoliteFaveRequest(ctx, fave); err != nil {
|
2024-08-24 11:49:37 +02:00
|
|
|
return gtserror.Newf("error pending fave: %w", err)
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Return early.
|
|
|
|
|
return nil
|
|
|
|
|
|
|
|
|
|
case pendingApproval && fave.PreApproved:
|
|
|
|
|
// If approval is required and fave is
|
|
|
|
|
// preapproved, that means this is a fave
|
|
|
|
|
// of one of our statuses with permission
|
|
|
|
|
// that matched on a following/followers
|
|
|
|
|
// collection. Do the Accept immediately and
|
|
|
|
|
// then process everything else as normal.
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// Store an already-accepted
|
|
|
|
|
// impolite interaction request.
|
|
|
|
|
requestID := id.NewULID()
|
2024-08-24 11:49:37 +02:00
|
|
|
approval := >smodel.InteractionRequest{
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
ID: requestID,
|
|
|
|
|
TargetStatusID: fave.StatusID,
|
|
|
|
|
TargetAccountID: fave.TargetAccountID,
|
|
|
|
|
TargetAccount: fave.TargetAccount,
|
|
|
|
|
InteractingAccountID: fave.AccountID,
|
|
|
|
|
InteractingAccount: fave.Account,
|
|
|
|
|
InteractionRequestURI: gtsmodel.ForwardCompatibleInteractionRequestURI(fave.URI, gtsmodel.LikeRequestSuffix),
|
|
|
|
|
InteractionURI: fave.URI,
|
|
|
|
|
InteractionType: gtsmodel.InteractionLike,
|
|
|
|
|
Polite: util.Ptr(false),
|
|
|
|
|
Like: fave,
|
|
|
|
|
ResponseURI: uris.GenerateURIForAccept(fave.TargetAccount.Username, requestID),
|
|
|
|
|
AuthorizationURI: uris.GenerateURIForAuthorization(fave.TargetAccount.Username, requestID),
|
|
|
|
|
AcceptedAt: time.Now(),
|
2024-08-24 11:49:37 +02:00
|
|
|
}
|
2024-08-24 14:17:55 +02:00
|
|
|
if err := p.state.DB.PutInteractionRequest(ctx, approval); err != nil {
|
|
|
|
|
return gtserror.Newf("db error putting pre-approved interaction request: %w", err)
|
|
|
|
|
}
|
2024-08-24 11:49:37 +02:00
|
|
|
|
|
|
|
|
// Mark the fave itself as now approved.
|
|
|
|
|
fave.PendingApproval = util.Ptr(false)
|
|
|
|
|
fave.PreApproved = false
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
fave.ApprovedByURI = approval.AuthorizationURI
|
2024-08-24 11:49:37 +02:00
|
|
|
if err := p.state.DB.UpdateStatusFave(
|
|
|
|
|
ctx,
|
|
|
|
|
fave,
|
|
|
|
|
"pending_approval",
|
|
|
|
|
"approved_by_uri",
|
|
|
|
|
); err != nil {
|
|
|
|
|
return gtserror.Newf("db error updating status fave: %w", err)
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Send out the approval as Accept.
|
|
|
|
|
if err := p.federate.AcceptInteraction(ctx, approval); err != nil {
|
|
|
|
|
return gtserror.Newf("error federating pre-approval of fave: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Don't return, just continue as normal.
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
if err := p.surface.notifyFave(ctx, fave); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error notifying fave: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Interaction counts changed on the faved status;
|
|
|
|
|
// uncache the prepared version from all timelines.
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
p.surface.invalidateStatusFromTimelines(fave.StatusID)
|
2023-08-09 19:14:33 +02:00
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// CreateLikeRequest handles a polite LikeRequest, as
|
|
|
|
|
// opposed to CreateLike, which handles *impolite* like
|
|
|
|
|
// requests (ie., Likes sent directly).
|
|
|
|
|
func (p *fediAPI) CreateLikeRequest(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
req, ok := fMsg.GTSModel.(*gtsmodel.InteractionRequest)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.InteractionRequest", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// At this point the not-yet-approved
|
|
|
|
|
// interaction request, and the pending
|
|
|
|
|
// fave, are both in the database.
|
|
|
|
|
|
|
|
|
|
if !req.Like.PreApproved {
|
|
|
|
|
// The fave is *not* pre-approved, and
|
|
|
|
|
// therefore requires manual approval.
|
|
|
|
|
//
|
|
|
|
|
// Just notify target account about
|
|
|
|
|
// the requested interaction.
|
|
|
|
|
if err := p.surface.notifyPendingFave(ctx, req.Like); err != nil {
|
|
|
|
|
return gtserror.Newf("error notifying pending like: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// If it's pre-approved on the other hand
|
|
|
|
|
// we can handle everything immediately.
|
|
|
|
|
|
|
|
|
|
// Mark the request as accepted.
|
|
|
|
|
req.AcceptedAt = time.Now()
|
|
|
|
|
req.ResponseURI = uris.GenerateURIForAccept(
|
|
|
|
|
req.TargetAccount.Username, req.ID,
|
|
|
|
|
)
|
|
|
|
|
req.AuthorizationURI = uris.GenerateURIForAuthorization(
|
|
|
|
|
req.TargetAccount.Username, req.ID,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
// Update in the db.
|
|
|
|
|
if err := p.state.DB.UpdateInteractionRequest(
|
|
|
|
|
ctx,
|
|
|
|
|
req,
|
|
|
|
|
"accepted_at",
|
|
|
|
|
"response_uri",
|
|
|
|
|
"authorization_uri",
|
|
|
|
|
); err != nil {
|
|
|
|
|
return gtserror.Newf("db error updating interaction request: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Send out the accept.
|
|
|
|
|
if err := p.federate.AcceptInteraction(ctx, req); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error federating accept: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Mark the fave as approved.
|
|
|
|
|
req.Like.PendingApproval = util.Ptr(false)
|
|
|
|
|
req.Like.ApprovedByURI = req.AuthorizationURI
|
|
|
|
|
req.Like.PreApproved = false
|
|
|
|
|
|
|
|
|
|
// Update in the db.
|
|
|
|
|
if err := p.state.DB.UpdateStatusFave(
|
|
|
|
|
ctx,
|
|
|
|
|
req.Like,
|
|
|
|
|
"pending_approval",
|
|
|
|
|
"approved_by_uri",
|
|
|
|
|
); err != nil {
|
|
|
|
|
return gtserror.Newf("db error updating status fave: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Notify the faved account.
|
|
|
|
|
if err := p.surface.notifyFave(ctx, req.Like); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error notifying fave: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Interaction counts changed on the faved status;
|
|
|
|
|
// uncache the prepared version from all timelines.
|
|
|
|
|
p.surface.invalidateStatusFromTimelines(req.Like.StatusID)
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *fediAPI) CreateAnnounce(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2023-12-01 15:27:15 +01:00
|
|
|
boost, ok := fMsg.GTSModel.(*gtsmodel.Status)
|
2023-08-09 19:14:33 +02:00
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.Status", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
2024-07-26 12:04:28 +02:00
|
|
|
// Dereference into a boost wrapper status.
|
|
|
|
|
//
|
|
|
|
|
// Note: this will handle storing the boost in
|
2023-12-01 15:27:15 +01:00
|
|
|
// the db, and dereferencing the target status
|
2023-11-04 20:21:20 +00:00
|
|
|
// ancestors / descendants where appropriate.
|
2023-12-01 15:27:15 +01:00
|
|
|
var err error
|
|
|
|
|
boost, err = p.federate.EnrichAnnounce(
|
|
|
|
|
ctx,
|
|
|
|
|
boost,
|
2024-04-26 13:50:46 +01:00
|
|
|
fMsg.Receiving.Username,
|
2023-12-01 15:27:15 +01:00
|
|
|
)
|
2023-08-09 19:14:33 +02:00
|
|
|
if err != nil {
|
2024-07-26 12:04:28 +02:00
|
|
|
if gtserror.IsUnretrievable(err) ||
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
gtserror.IsNotPermitted(err) {
|
2024-07-26 12:04:28 +02:00
|
|
|
// Boosted status domain blocked, or
|
|
|
|
|
// otherwise not permitted, nothing to do.
|
2023-12-01 15:27:15 +01:00
|
|
|
log.Debugf(ctx, "skipping announce: %v", err)
|
|
|
|
|
return nil
|
|
|
|
|
}
|
2023-08-09 19:14:33 +02:00
|
|
|
|
2023-12-01 15:27:15 +01:00
|
|
|
// Actual error.
|
|
|
|
|
return gtserror.Newf("error dereferencing announce: %w", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
2024-07-26 12:04:28 +02:00
|
|
|
// If pending approval is true then
|
|
|
|
|
// boost must target a LOCAL status
|
|
|
|
|
// that requires approval for the boost.
|
2024-08-24 11:49:37 +02:00
|
|
|
pendingApproval := util.PtrOrZero(boost.PendingApproval)
|
2024-07-26 12:04:28 +02:00
|
|
|
|
|
|
|
|
switch {
|
|
|
|
|
case pendingApproval && !boost.PreApproved:
|
|
|
|
|
// If approval is required and boost isn't
|
|
|
|
|
// preapproved, then just notify the account
|
|
|
|
|
// that's being interacted with: they can
|
|
|
|
|
// approve or deny the interaction later.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
if err := p.utils.impoliteAnnounceRequest(ctx, boost); err != nil {
|
2024-08-24 11:49:37 +02:00
|
|
|
return gtserror.Newf("error pending boost: %w", err)
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Return early.
|
|
|
|
|
return nil
|
|
|
|
|
|
|
|
|
|
case pendingApproval && boost.PreApproved:
|
|
|
|
|
// If approval is required and status is
|
|
|
|
|
// preapproved, that means this is a boost
|
|
|
|
|
// of one of our statuses with permission
|
|
|
|
|
// that matched on a following/followers
|
|
|
|
|
// collection. Do the Accept immediately and
|
|
|
|
|
// then process everything else as normal.
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// Store an already-accepted
|
|
|
|
|
// impolite interaction request.
|
|
|
|
|
requestID := id.NewULID()
|
2024-08-24 11:49:37 +02:00
|
|
|
approval := >smodel.InteractionRequest{
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
ID: requestID,
|
|
|
|
|
TargetStatusID: boost.BoostOfID,
|
|
|
|
|
TargetAccountID: boost.BoostOfAccountID,
|
|
|
|
|
TargetAccount: boost.BoostOfAccount,
|
|
|
|
|
InteractingAccountID: boost.AccountID,
|
|
|
|
|
InteractingAccount: boost.Account,
|
|
|
|
|
InteractionRequestURI: gtsmodel.ForwardCompatibleInteractionRequestURI(boost.URI, gtsmodel.AnnounceRequestSuffix),
|
|
|
|
|
InteractionURI: boost.URI,
|
|
|
|
|
InteractionType: gtsmodel.InteractionAnnounce,
|
|
|
|
|
Polite: util.Ptr(false),
|
|
|
|
|
Announce: boost,
|
|
|
|
|
ResponseURI: uris.GenerateURIForAccept(boost.BoostOfAccount.Username, requestID),
|
|
|
|
|
AuthorizationURI: uris.GenerateURIForAuthorization(boost.BoostOfAccount.Username, requestID),
|
|
|
|
|
AcceptedAt: time.Now(),
|
2024-08-24 11:49:37 +02:00
|
|
|
}
|
2024-08-24 14:17:55 +02:00
|
|
|
if err := p.state.DB.PutInteractionRequest(ctx, approval); err != nil {
|
|
|
|
|
return gtserror.Newf("db error putting pre-approved interaction request: %w", err)
|
|
|
|
|
}
|
2024-08-24 11:49:37 +02:00
|
|
|
|
|
|
|
|
// Mark the boost itself as now approved.
|
|
|
|
|
boost.PendingApproval = util.Ptr(false)
|
|
|
|
|
boost.PreApproved = false
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
boost.ApprovedByURI = approval.AuthorizationURI
|
2024-08-24 11:49:37 +02:00
|
|
|
if err := p.state.DB.UpdateStatus(
|
|
|
|
|
ctx,
|
|
|
|
|
boost,
|
|
|
|
|
"pending_approval",
|
|
|
|
|
"approved_by_uri",
|
|
|
|
|
); err != nil {
|
|
|
|
|
return gtserror.Newf("db error updating status: %w", err)
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Send out the approval as Accept.
|
|
|
|
|
if err := p.federate.AcceptInteraction(ctx, approval); err != nil {
|
|
|
|
|
return gtserror.Newf("error federating pre-approval of boost: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Don't return, just continue as normal.
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-16 13:10:13 +02:00
|
|
|
// Update stats for the remote account.
|
2024-04-26 13:50:46 +01:00
|
|
|
if err := p.utils.incrementStatusesCount(ctx, fMsg.Requesting, boost); err != nil {
|
2024-04-16 13:10:13 +02:00
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
// Timeline and notify the announce.
|
2023-12-01 15:27:15 +01:00
|
|
|
if err := p.surface.timelineAndNotifyStatus(ctx, boost); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error timelining and notifying status: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
2023-12-01 15:27:15 +01:00
|
|
|
if err := p.surface.notifyAnnounce(ctx, boost); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error notifying announce: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
2023-12-01 10:53:53 +00:00
|
|
|
// Interaction counts changed on the original status;
|
2023-08-09 19:14:33 +02:00
|
|
|
// uncache the prepared version from all timelines.
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
p.surface.invalidateStatusFromTimelines(boost.BoostOfID)
|
2023-08-09 19:14:33 +02:00
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
func (p *fediAPI) CreateAnnounceRequest(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
req, ok := fMsg.GTSModel.(*gtsmodel.InteractionRequest)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.InteractionRequest", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// At this point the not-yet-handled interaction req
|
|
|
|
|
// is in the database, but the announce isn't yet.
|
|
|
|
|
//
|
|
|
|
|
// We can check permissions for the announce *and*
|
|
|
|
|
// put it in the db (if acceptable) by doing Enrich.
|
|
|
|
|
boost, err := p.federate.EnrichAnnounce(
|
|
|
|
|
ctx,
|
|
|
|
|
req.Announce,
|
|
|
|
|
fMsg.Receiving.Username,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
switch {
|
|
|
|
|
case err == nil:
|
|
|
|
|
// All fine.
|
|
|
|
|
|
|
|
|
|
case gtserror.IsNotPermitted(err):
|
|
|
|
|
// Announce is straight up not permitted
|
|
|
|
|
// by the interaction policy of the status
|
|
|
|
|
// it's targeting. Nothing more to do.
|
|
|
|
|
log.Debugf(ctx,
|
|
|
|
|
"dropping unpermitted AnnounceRequest with instrument %s",
|
|
|
|
|
req.Announce.URI,
|
|
|
|
|
)
|
|
|
|
|
return nil
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
// There's some real error.
|
|
|
|
|
return gtserror.Newf(
|
|
|
|
|
"error processing AnnounceRequest with instrument %s: %w",
|
|
|
|
|
req.Announce.URI, err,
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// The announce is permitted. Check if we
|
|
|
|
|
// should send out an Accept immediately.
|
|
|
|
|
manualApproval := *boost.PendingApproval && !boost.PreApproved
|
|
|
|
|
if manualApproval {
|
|
|
|
|
// The announce requires manual approval.
|
|
|
|
|
//
|
|
|
|
|
// Just notify target account about
|
|
|
|
|
// the requested interaction.
|
|
|
|
|
if err := p.surface.notifyPendingAnnounce(ctx, boost); err != nil {
|
|
|
|
|
return gtserror.Newf("error notifying pending announce: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// The announce is automatically approved,
|
|
|
|
|
// mark the request as accepted.
|
|
|
|
|
req.AcceptedAt = time.Now()
|
|
|
|
|
req.ResponseURI = uris.GenerateURIForAccept(
|
|
|
|
|
req.TargetAccount.Username, req.ID,
|
|
|
|
|
)
|
|
|
|
|
req.AuthorizationURI = uris.GenerateURIForAuthorization(
|
|
|
|
|
req.TargetAccount.Username, req.ID,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
// Update in the db.
|
|
|
|
|
if err := p.state.DB.UpdateInteractionRequest(
|
|
|
|
|
ctx,
|
|
|
|
|
req,
|
|
|
|
|
"accepted_at",
|
|
|
|
|
"response_uri",
|
|
|
|
|
"authorization_uri",
|
|
|
|
|
); err != nil {
|
|
|
|
|
return gtserror.Newf("db error updating interaction request: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Send out the accept.
|
|
|
|
|
if err := p.federate.AcceptInteraction(ctx, req); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error federating accept: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Update stats for the boosting account.
|
|
|
|
|
if err := p.utils.incrementStatusesCount(ctx, fMsg.Requesting, boost); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Timeline the boost + notify recipient(s).
|
|
|
|
|
if err := p.surface.timelineAndNotifyStatus(ctx, boost); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error timelining and notifying status: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Interaction counts changed on the boosted status;
|
|
|
|
|
// uncache the prepared version from all timelines.
|
|
|
|
|
p.surface.invalidateStatusFromTimelines(boost.BoostOfID)
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *fediAPI) CreateBlock(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2023-08-09 19:14:33 +02:00
|
|
|
block, ok := fMsg.GTSModel.(*gtsmodel.Block)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.Block", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
if block.Account.IsLocal() {
|
|
|
|
|
// Remove posts by target from origin's timelines.
|
|
|
|
|
p.surface.removeRelationshipFromTimelines(ctx,
|
|
|
|
|
block.AccountID,
|
|
|
|
|
block.TargetAccountID,
|
|
|
|
|
)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
if block.TargetAccount.IsLocal() {
|
|
|
|
|
// Remove posts by origin from target's timelines.
|
|
|
|
|
p.surface.removeRelationshipFromTimelines(ctx,
|
|
|
|
|
block.TargetAccountID,
|
|
|
|
|
block.AccountID,
|
|
|
|
|
)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Remove any follows that existed between blocker + blockee.
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
// (note this handles removing any necessary list entries).
|
|
|
|
|
if err := p.state.DB.DeleteFollow(ctx,
|
2023-08-09 19:14:33 +02:00
|
|
|
block.AccountID,
|
|
|
|
|
block.TargetAccountID,
|
|
|
|
|
); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error deleting follow from block -> target: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
if err := p.state.DB.DeleteFollow(ctx,
|
2023-08-09 19:14:33 +02:00
|
|
|
block.TargetAccountID,
|
|
|
|
|
block.AccountID,
|
|
|
|
|
); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error deleting follow from target -> block: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Remove any follow requests that existed between blocker + blockee.
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
if err := p.state.DB.DeleteFollowRequest(ctx,
|
2023-08-09 19:14:33 +02:00
|
|
|
block.AccountID,
|
|
|
|
|
block.TargetAccountID,
|
|
|
|
|
); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error deleting follow request from block -> target: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
if err := p.state.DB.DeleteFollowRequest(ctx,
|
2023-08-09 19:14:33 +02:00
|
|
|
block.TargetAccountID,
|
|
|
|
|
block.AccountID,
|
|
|
|
|
); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error deleting follow request from target -> block: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *fediAPI) CreateFlag(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2023-08-09 19:14:33 +02:00
|
|
|
incomingReport, ok := fMsg.GTSModel.(*gtsmodel.Report)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.Report", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// TODO: handle additional side effects of flag creation:
|
|
|
|
|
// - notify admins by dm / notification
|
|
|
|
|
|
2024-04-11 11:45:53 +02:00
|
|
|
if err := p.surface.emailAdminReportOpened(ctx, incomingReport); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error emailing report opened: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *fediAPI) UpdateAccount(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2023-08-09 19:14:33 +02:00
|
|
|
// Parse the old/existing account model.
|
|
|
|
|
account, ok := fMsg.GTSModel.(*gtsmodel.Account)
|
|
|
|
|
if !ok {
|
2023-10-04 13:09:42 +01:00
|
|
|
return gtserror.Newf("cannot cast %T -> *gtsmodel.Account", fMsg.GTSModel)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Because this was an Update, the new Accountable should be set on the message.
|
2024-04-26 13:50:46 +01:00
|
|
|
apubAcc, ok := fMsg.APObject.(ap.Accountable)
|
2023-08-09 19:14:33 +02:00
|
|
|
if !ok {
|
2024-04-26 13:50:46 +01:00
|
|
|
return gtserror.Newf("cannot cast %T -> ap.Accountable", fMsg.APObject)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Fetch up-to-date bio, avatar, header, etc.
|
|
|
|
|
_, _, err := p.federate.RefreshAccount(
|
|
|
|
|
ctx,
|
2024-04-26 13:50:46 +01:00
|
|
|
fMsg.Receiving.Username,
|
2023-08-09 19:14:33 +02:00
|
|
|
account,
|
|
|
|
|
apubAcc,
|
2024-08-13 15:37:09 +00:00
|
|
|
|
2024-12-23 17:54:44 +00:00
|
|
|
// Force refresh within 5s window.
|
2024-08-13 15:37:09 +00:00
|
|
|
//
|
|
|
|
|
// Missing account updates could be
|
|
|
|
|
// detrimental to federation if they
|
|
|
|
|
// include public key changes.
|
|
|
|
|
dereferencing.Freshest,
|
2023-08-09 19:14:33 +02:00
|
|
|
)
|
|
|
|
|
if err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error refreshing account: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
2025-05-02 16:01:30 +00:00
|
|
|
// Account representation has changed, invalidate from timelines.
|
|
|
|
|
p.surface.invalidateTimelineEntriesByAccount(account.ID)
|
|
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *fediAPI) AcceptFollow(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2024-04-16 13:10:13 +02:00
|
|
|
// Update stats for the remote account.
|
2024-04-26 13:50:46 +01:00
|
|
|
if err := p.utils.decrementFollowRequestsCount(ctx, fMsg.Requesting); err != nil {
|
2024-04-16 13:10:13 +02:00
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
if err := p.utils.incrementFollowersCount(ctx, fMsg.Requesting); err != nil {
|
2024-04-16 13:10:13 +02:00
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Update stats for the local account.
|
2024-04-26 13:50:46 +01:00
|
|
|
if err := p.utils.incrementFollowingCount(ctx, fMsg.Receiving); err != nil {
|
2024-04-16 13:10:13 +02:00
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-07-26 12:04:28 +02:00
|
|
|
func (p *fediAPI) AcceptLike(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
// TODO: Add something here if we ever implement sending out Likes to
|
|
|
|
|
// followers more broadly and not just the owner of the Liked status.
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (p *fediAPI) AcceptReply(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
reply, ok := fMsg.GTSModel.(*gtsmodel.Status)
|
2024-07-26 12:04:28 +02:00
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.Status", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Update stats for the actor account.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
if err := p.utils.incrementStatusesCount(ctx, reply.Account, reply); err != nil {
|
2024-07-26 12:04:28 +02:00
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Timeline and notify the status.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
if err := p.surface.timelineAndNotifyStatus(ctx, reply); err != nil {
|
2024-07-26 12:04:28 +02:00
|
|
|
log.Errorf(ctx, "error timelining and notifying status: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Send out the reply again, fully this time.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
if err := p.federate.CreateStatus(ctx, reply); err != nil {
|
2024-07-26 12:04:28 +02:00
|
|
|
log.Errorf(ctx, "error federating announce: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
2024-08-24 11:49:37 +02:00
|
|
|
// Interaction counts changed on the replied-to status;
|
|
|
|
|
// uncache the prepared version from all timelines.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
p.surface.invalidateStatusFromTimelines(reply.InReplyToID)
|
2024-08-24 11:49:37 +02:00
|
|
|
|
2024-07-26 12:04:28 +02:00
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
func (p *fediAPI) AcceptRemoteStatus(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
// See if we can accept a remote
|
|
|
|
|
// status we don't have stored yet.
|
|
|
|
|
objectIRI, ok := fMsg.APObject.(*url.URL)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *url.URL", fMsg.APObject)
|
|
|
|
|
}
|
|
|
|
|
|
2025-02-19 18:09:54 +01:00
|
|
|
approvedByURI := fMsg.APIRI
|
|
|
|
|
if approvedByURI == nil {
|
|
|
|
|
return gtserror.New("approvedByURI was nil")
|
2024-10-08 10:51:13 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Assume we're accepting a status; create a
|
|
|
|
|
// barebones status for dereferencing purposes.
|
|
|
|
|
bareStatus := >smodel.Status{
|
|
|
|
|
URI: objectIRI.String(),
|
2025-02-19 18:09:54 +01:00
|
|
|
ApprovedByURI: approvedByURI.String(),
|
2024-10-08 10:51:13 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Call RefreshStatus() to process the provided
|
|
|
|
|
// barebones status and insert it into the database,
|
|
|
|
|
// if indeed it's actually a status URI we can fetch.
|
|
|
|
|
//
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// This will also check whether the given approvedByURI
|
2024-10-08 10:51:13 +02:00
|
|
|
// actually grants permission for this status.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
reply, _, err := p.federate.RefreshStatus(ctx,
|
2024-10-08 10:51:13 +02:00
|
|
|
fMsg.Receiving.Username,
|
|
|
|
|
bareStatus,
|
|
|
|
|
nil, nil,
|
|
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return gtserror.Newf("error processing accepted status %s: %w", bareStatus.URI, err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// No error means it was indeed a remote status, and the
|
2025-02-19 18:09:54 +01:00
|
|
|
// given approvedByURI permitted it. Timeline and notify it.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
if err := p.surface.timelineAndNotifyStatus(ctx, reply); err != nil {
|
2024-10-08 10:51:13 +02:00
|
|
|
log.Errorf(ctx, "error timelining and notifying status: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Interaction counts changed on the interacted status;
|
|
|
|
|
// uncache the prepared version from all timelines.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
if reply.InReplyToID != "" {
|
|
|
|
|
p.surface.invalidateStatusFromTimelines(reply.InReplyToID)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if reply.BoostOfID != "" {
|
|
|
|
|
p.surface.invalidateStatusFromTimelines(reply.BoostOfID)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (p *fediAPI) AcceptPoliteReplyRequest(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
if util.IsNil(fMsg.GTSModel) {
|
|
|
|
|
// If the interaction request is nil, this
|
|
|
|
|
// must be an accept of a remote ReplyRequest
|
|
|
|
|
// not targeting one of our statuses.
|
|
|
|
|
//
|
|
|
|
|
// Just pass it to the AcceptRemoteStatus
|
|
|
|
|
// func to do dereferencing + side effects.
|
|
|
|
|
log.Debug(ctx, "accepting remote ReplyRequest for remote reply")
|
|
|
|
|
return p.AcceptRemoteStatus(ctx, fMsg)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// If the interaction request is not nil, this will
|
|
|
|
|
// be an accept of one of our replies to a remote.
|
|
|
|
|
//
|
|
|
|
|
// Since the int req + reply have already been updated
|
|
|
|
|
// in the federatingDB, we just need to do side effects.
|
|
|
|
|
intReq, ok := fMsg.GTSModel.(*gtsmodel.InteractionRequest)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.InteractionRequest", fMsg.GTSModel)
|
2024-10-08 10:51:13 +02:00
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// Ensure reply populated.
|
|
|
|
|
reply := intReq.Reply
|
|
|
|
|
if err := p.state.DB.PopulateStatus(ctx, reply); err != nil {
|
|
|
|
|
return gtserror.Newf("error populating status: %w", err)
|
2024-10-08 10:51:13 +02:00
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
// Update stats for the actor account.
|
|
|
|
|
if err := p.utils.incrementStatusesCount(ctx, reply.Account, reply); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Timeline and notify the status.
|
|
|
|
|
if err := p.surface.timelineAndNotifyStatus(ctx, reply); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error timelining and notifying status: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Send out the reply with approval attached.
|
|
|
|
|
if err := p.federate.CreateStatus(ctx, reply); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error federating announce: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Interaction counts changed on the replied-to status;
|
|
|
|
|
// uncache the prepared version from all timelines.
|
|
|
|
|
p.surface.invalidateStatusFromTimelines(reply.InReplyToID)
|
|
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-07-26 12:04:28 +02:00
|
|
|
func (p *fediAPI) AcceptAnnounce(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
boost, ok := fMsg.GTSModel.(*gtsmodel.Status)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.Status", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Update stats for the actor account.
|
|
|
|
|
if err := p.utils.incrementStatusesCount(ctx, boost.Account, boost); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Timeline and notify the boost wrapper status.
|
|
|
|
|
if err := p.surface.timelineAndNotifyStatus(ctx, boost); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error timelining and notifying status: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Send out the boost again, fully this time.
|
|
|
|
|
if err := p.federate.Announce(ctx, boost); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error federating announce: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
2024-08-24 11:49:37 +02:00
|
|
|
// Interaction counts changed on the boosted status;
|
|
|
|
|
// uncache the prepared version from all timelines.
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
p.surface.invalidateStatusFromTimelines(boost.BoostOfID)
|
2024-08-24 11:49:37 +02:00
|
|
|
|
2024-07-26 12:04:28 +02:00
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *fediAPI) UpdateStatus(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2023-10-04 13:09:42 +01:00
|
|
|
// Cast the existing Status model attached to msg.
|
|
|
|
|
existing, ok := fMsg.GTSModel.(*gtsmodel.Status)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("cannot cast %T -> *gtsmodel.Status", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
2024-12-23 17:54:44 +00:00
|
|
|
var freshness *dereferencing.FreshnessWindow
|
|
|
|
|
|
2023-10-04 13:09:42 +01:00
|
|
|
// Cast the updated ActivityPub statusable object .
|
2024-04-26 13:50:46 +01:00
|
|
|
apStatus, _ := fMsg.APObject.(ap.Statusable)
|
2023-10-04 13:09:42 +01:00
|
|
|
|
2024-12-23 17:54:44 +00:00
|
|
|
if apStatus != nil {
|
|
|
|
|
// If an AP object was provided, we
|
|
|
|
|
// allow very fast refreshes that likely
|
|
|
|
|
// indicate a status edit after post.
|
|
|
|
|
freshness = dereferencing.Freshest
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-04 13:09:42 +01:00
|
|
|
// Fetch up-to-date attach status attachments, etc.
|
2023-11-08 14:32:17 +00:00
|
|
|
status, _, err := p.federate.RefreshStatus(
|
2023-10-04 13:09:42 +01:00
|
|
|
ctx,
|
2024-04-26 13:50:46 +01:00
|
|
|
fMsg.Receiving.Username,
|
2023-10-04 13:09:42 +01:00
|
|
|
existing,
|
|
|
|
|
apStatus,
|
2024-12-23 17:54:44 +00:00
|
|
|
freshness,
|
2023-10-04 13:09:42 +01:00
|
|
|
)
|
|
|
|
|
if err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error refreshing status: %v", err)
|
2023-10-04 13:09:42 +01:00
|
|
|
}
|
|
|
|
|
|
2023-11-08 14:32:17 +00:00
|
|
|
if status.Poll != nil && status.Poll.Closing {
|
|
|
|
|
|
|
|
|
|
// If the latest status has a newly closed poll, at least compared
|
|
|
|
|
// to the existing version, then notify poll close to all voters.
|
|
|
|
|
if err := p.surface.notifyPollClose(ctx, status); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error sending poll notification: %v", err)
|
|
|
|
|
}
|
2023-11-04 20:21:20 +00:00
|
|
|
}
|
|
|
|
|
|
2025-05-04 09:45:10 +00:00
|
|
|
// Notify any *new* mentions added
|
|
|
|
|
// to this status by the editor.
|
|
|
|
|
for _, mention := range status.Mentions {
|
|
|
|
|
// Check if we've seen
|
|
|
|
|
// this mention already.
|
|
|
|
|
if !mention.IsNew {
|
|
|
|
|
// Already seen
|
|
|
|
|
// it, skip.
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Haven't seen this mention
|
|
|
|
|
// yet, notify it if necessary.
|
|
|
|
|
mention.Status = status
|
|
|
|
|
if err := p.surface.notifyMention(ctx, mention); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error notifying mention: %v", err)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2025-05-31 17:30:57 +02:00
|
|
|
if len(status.EditIDs) > 0 {
|
|
|
|
|
// Ensure edits are fully populated for this status before anything.
|
|
|
|
|
if err := p.surface.State.DB.PopulateStatusEdits(ctx, status); err != nil {
|
|
|
|
|
log.Error(ctx, "error populating updated status edits: %v")
|
|
|
|
|
|
|
|
|
|
// Then send notifications of a status edit
|
|
|
|
|
// to any local interactors of the status.
|
|
|
|
|
} else if err := p.surface.notifyStatusEdit(ctx,
|
|
|
|
|
status,
|
|
|
|
|
status.Edits[len(status.Edits)-1], // latest
|
|
|
|
|
); err != nil {
|
2025-05-11 13:38:13 +00:00
|
|
|
log.Errorf(ctx, "error notifying status edit: %v", err)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2025-05-05 09:22:03 +00:00
|
|
|
// Push message that the status has been edited to streams.
|
|
|
|
|
if err := p.surface.timelineStatusUpdate(ctx, status); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error streaming status edit: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
2025-05-04 09:45:10 +00:00
|
|
|
// Status representation changed, uncache from timelines.
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
p.surface.invalidateStatusFromTimelines(status.ID)
|
2024-08-24 11:49:37 +02:00
|
|
|
|
2023-10-04 13:09:42 +01:00
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *fediAPI) DeleteStatus(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2023-08-09 19:14:33 +02:00
|
|
|
status, ok := fMsg.GTSModel.(*gtsmodel.Status)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.Status", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
// Try to populate status structs if possible,
|
|
|
|
|
// in order to more thoroughly remove them.
|
|
|
|
|
if err := p.state.DB.PopulateStatus(
|
|
|
|
|
ctx, status,
|
|
|
|
|
); err != nil && !errors.Is(err, db.ErrNoEntries) {
|
|
|
|
|
return gtserror.Newf("db error populating status: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Drop any outgoing queued AP requests about / targeting
|
|
|
|
|
// this status, (stops queued likes, boosts, creates etc).
|
|
|
|
|
p.state.Workers.Delivery.Queue.Delete("ObjectID", status.URI)
|
|
|
|
|
p.state.Workers.Delivery.Queue.Delete("TargetID", status.URI)
|
|
|
|
|
|
|
|
|
|
// Drop any incoming queued client messages about / targeting
|
|
|
|
|
// status, (stops processing of local origin data for status).
|
|
|
|
|
p.state.Workers.Client.Queue.Delete("TargetURI", status.URI)
|
|
|
|
|
|
|
|
|
|
// Drop any incoming queued federator messages targeting status,
|
|
|
|
|
// (stops processing of remote origin data targeting this status).
|
|
|
|
|
p.state.Workers.Federator.Queue.Delete("TargetURI", status.URI)
|
|
|
|
|
|
2024-09-10 14:34:49 +02:00
|
|
|
// Delete attachments from this status, since this request
|
|
|
|
|
// comes from the federating API, and there's no way the
|
|
|
|
|
// poster can do a delete + redraft for it on our instance.
|
|
|
|
|
const deleteAttachments = true
|
|
|
|
|
|
|
|
|
|
// This is just a deletion, not a Reject,
|
|
|
|
|
// we don't need to take a copy of this status.
|
|
|
|
|
const copyToSinBin = false
|
|
|
|
|
|
|
|
|
|
// Perform the actual status deletion.
|
|
|
|
|
if err := p.utils.wipeStatus(
|
|
|
|
|
ctx,
|
|
|
|
|
status,
|
|
|
|
|
deleteAttachments,
|
|
|
|
|
copyToSinBin,
|
|
|
|
|
); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error wiping status: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
2024-04-16 13:10:13 +02:00
|
|
|
// Update stats for the remote account.
|
2024-08-11 09:23:36 +00:00
|
|
|
if err := p.utils.decrementStatusesCount(ctx, fMsg.Requesting, status); err != nil {
|
2024-04-16 13:10:13 +02:00
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-09 19:14:33 +02:00
|
|
|
if status.InReplyToID != "" {
|
|
|
|
|
// Interaction counts changed on the replied status;
|
|
|
|
|
// uncache the prepared version from all timelines.
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
p.surface.invalidateStatusFromTimelines(status.InReplyToID)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
func (p *fediAPI) DeleteAccount(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
2023-08-09 19:14:33 +02:00
|
|
|
account, ok := fMsg.GTSModel.(*gtsmodel.Account)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.Account", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-26 13:50:46 +01:00
|
|
|
// Drop any outgoing queued AP requests to / from / targeting
|
|
|
|
|
// this account, (stops queued likes, boosts, creates etc).
|
|
|
|
|
p.state.Workers.Delivery.Queue.Delete("ObjectID", account.URI)
|
|
|
|
|
p.state.Workers.Delivery.Queue.Delete("TargetID", account.URI)
|
|
|
|
|
|
|
|
|
|
// Drop any incoming queued client messages to / from this
|
|
|
|
|
// account, (stops processing of local origin data for acccount).
|
|
|
|
|
p.state.Workers.Client.Queue.Delete("Target.ID", account.ID)
|
|
|
|
|
p.state.Workers.Client.Queue.Delete("TargetURI", account.URI)
|
|
|
|
|
|
|
|
|
|
// Drop any incoming queued federator messages to this account,
|
|
|
|
|
// (stops processing of remote origin data targeting this account).
|
|
|
|
|
p.state.Workers.Federator.Queue.Delete("Requesting.ID", account.ID)
|
|
|
|
|
p.state.Workers.Federator.Queue.Delete("TargetURI", account.URI)
|
|
|
|
|
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
// Remove any entries authored by account from timelines.
|
|
|
|
|
p.surface.removeTimelineEntriesByAccount(account.ID)
|
|
|
|
|
|
2025-06-11 11:38:10 +02:00
|
|
|
// And finally, perform the actual account deletion synchronously.
|
2023-08-09 19:14:33 +02:00
|
|
|
if err := p.account.Delete(ctx, account, account.ID); err != nil {
|
2023-11-08 14:32:17 +00:00
|
|
|
log.Errorf(ctx, "error deleting account: %v", err)
|
2023-08-09 19:14:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
2024-09-10 14:34:49 +02:00
|
|
|
|
|
|
|
|
func (p *fediAPI) RejectLike(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
req, ok := fMsg.GTSModel.(*gtsmodel.InteractionRequest)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.InteractionRequest", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// At this point the InteractionRequest should already
|
|
|
|
|
// be in the database, we just need to do side effects.
|
|
|
|
|
|
|
|
|
|
// Send out the Reject.
|
|
|
|
|
if err := p.federate.RejectInteraction(ctx, req); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error federating rejection of like: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Get the rejected fave.
|
|
|
|
|
fave, err := p.state.DB.GetStatusFaveByURI(
|
|
|
|
|
gtscontext.SetBarebones(ctx),
|
|
|
|
|
req.InteractionURI,
|
|
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return gtserror.Newf("db error getting rejected fave: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Delete the fave.
|
|
|
|
|
if err := p.state.DB.DeleteStatusFaveByID(ctx, fave.ID); err != nil {
|
|
|
|
|
return gtserror.Newf("db error deleting fave: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (p *fediAPI) RejectReply(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
req, ok := fMsg.GTSModel.(*gtsmodel.InteractionRequest)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.InteractionRequest", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// At this point the InteractionRequest should already
|
|
|
|
|
// be in the database, we just need to do side effects.
|
|
|
|
|
|
|
|
|
|
// Get the rejected status.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
reply, err := p.state.DB.GetStatusByURI(
|
2024-09-10 14:34:49 +02:00
|
|
|
gtscontext.SetBarebones(ctx),
|
|
|
|
|
req.InteractionURI,
|
|
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return gtserror.Newf("db error getting rejected reply: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Delete attachments from this status.
|
|
|
|
|
// It's rejected so there's no possibility
|
|
|
|
|
// for the poster to delete + redraft it.
|
|
|
|
|
const deleteAttachments = true
|
|
|
|
|
|
|
|
|
|
// Keep a copy of the status in
|
|
|
|
|
// the sin bin for future review.
|
|
|
|
|
const copyToSinBin = true
|
|
|
|
|
|
|
|
|
|
// Perform the actual status deletion.
|
|
|
|
|
if err := p.utils.wipeStatus(
|
|
|
|
|
ctx,
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~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>
2025-09-14 15:37:35 +02:00
|
|
|
reply,
|
2024-09-10 14:34:49 +02:00
|
|
|
deleteAttachments,
|
|
|
|
|
copyToSinBin,
|
|
|
|
|
); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error wiping reply: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (p *fediAPI) RejectAnnounce(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
req, ok := fMsg.GTSModel.(*gtsmodel.InteractionRequest)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.InteractionRequest", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// At this point the InteractionRequest should already
|
|
|
|
|
// be in the database, we just need to do side effects.
|
|
|
|
|
|
|
|
|
|
// Get the rejected boost.
|
|
|
|
|
boost, err := p.state.DB.GetStatusByURI(
|
|
|
|
|
gtscontext.SetBarebones(ctx),
|
|
|
|
|
req.InteractionURI,
|
|
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return gtserror.Newf("db error getting rejected announce: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Boosts don't have attachments anyway
|
|
|
|
|
// so it doesn't matter what we set here.
|
|
|
|
|
const deleteAttachments = true
|
|
|
|
|
|
|
|
|
|
// This is just a boost, don't
|
|
|
|
|
// keep a copy in the sin bin.
|
|
|
|
|
const copyToSinBin = true
|
|
|
|
|
|
|
|
|
|
// Perform the actual status deletion.
|
|
|
|
|
if err := p.utils.wipeStatus(
|
|
|
|
|
ctx,
|
|
|
|
|
boost,
|
|
|
|
|
deleteAttachments,
|
|
|
|
|
copyToSinBin,
|
|
|
|
|
); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error wiping announce: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
2025-01-24 16:36:34 +00:00
|
|
|
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
func (p *fediAPI) UndoFollow(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
follow, ok := fMsg.GTSModel.(*gtsmodel.Follow)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.Follow", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if follow.Account.IsLocal() {
|
|
|
|
|
// Remove posts by target from origin's timelines.
|
|
|
|
|
p.surface.removeRelationshipFromTimelines(ctx,
|
|
|
|
|
follow.AccountID,
|
|
|
|
|
follow.TargetAccountID,
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if follow.TargetAccount.IsLocal() {
|
|
|
|
|
// Remove posts by origin from target's timelines.
|
|
|
|
|
p.surface.removeRelationshipFromTimelines(ctx,
|
|
|
|
|
follow.TargetAccountID,
|
|
|
|
|
follow.AccountID,
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (p *fediAPI) UndoBlock(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
_, ok := fMsg.GTSModel.(*gtsmodel.Block)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.Block", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// TODO: any required changes
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-24 16:36:34 +00:00
|
|
|
func (p *fediAPI) UndoAnnounce(
|
|
|
|
|
ctx context.Context,
|
|
|
|
|
fMsg *messages.FromFediAPI,
|
|
|
|
|
) error {
|
|
|
|
|
boost, ok := fMsg.GTSModel.(*gtsmodel.Status)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.Status", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Delete the boost wrapper itself.
|
|
|
|
|
if err := p.state.DB.DeleteStatusByID(ctx, boost.ID); err != nil {
|
|
|
|
|
return gtserror.Newf("db error deleting boost: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Update statuses count for the requesting account.
|
|
|
|
|
if err := p.utils.decrementStatusesCount(ctx, fMsg.Requesting, boost); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error updating account stats: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Remove the boost wrapper from all timelines.
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
p.surface.deleteStatusFromTimelines(ctx, boost.ID)
|
2025-01-24 16:36:34 +00:00
|
|
|
|
|
|
|
|
// Interaction counts changed on the boosted status;
|
|
|
|
|
// uncache the prepared version from all timelines.
|
[performance] rewrite timelines to rely on new timeline cache type (#3941)
* start work rewriting timeline cache type
* further work rewriting timeline caching
* more work integration new timeline code
* remove old code
* add local timeline, fix up merge conflicts
* remove old use of go-bytes
* implement new timeline code into more areas of codebase, pull in latest go-mangler, go-mutexes, go-structr
* remove old timeline package, add local timeline cache
* remove references to old timeline types that needed starting up in tests
* start adding page validation
* fix test-identified timeline cache package issues
* fix up more tests, fix missing required changes, etc
* add exclusion for test.out in gitignore
* clarify some things better in code comments
* tweak cache size limits
* fix list timeline cache fetching
* further list timeline fixes
* linter, ssssssssshhhhhhhhhhhh please
* fix linter hints
* reslice the output if it's beyond length of 'lim'
* remove old timeline initialization code, bump go-structr to v0.9.4
* continued from previous commit
* improved code comments
* don't allow multiple entries for BoostOfID values to prevent repeated boosts of same boosts
* finish writing more code comments
* some variable renaming, for ease of following
* change the way we update lo,hi paging values during timeline load
* improved code comments for updated / returned lo , hi paging values
* finish writing code comments for the StatusTimeline{} type itself
* fill in more code comments
* update go-structr version to latest with changed timeline unique indexing logic
* have a local and public timeline *per user*
* rewrite calls to public / local timeline calls
* remove the zero length check, as lo, hi values might still be set
* simplify timeline cache loading, fix lo/hi returns, fix timeline invalidation side-effects missing for some federated actions
* swap the lo, hi values :facepalm:
* add (now) missing slice reverse of tag timeline statuses when paging ASC
* remove local / public caches (is out of scope for this work), share more timeline code
* remove unnecessary change
* again, remove more unused code
* remove unused function to appease the linter
* move boost checking to prepare function
* fix use of timeline.lastOrder, fix incorrect range functions used
* remove comments for repeat code
* remove the boost logic from prepare function
* do a maximum of 5 loads, not 10
* add repeat boost filtering logic, update go-structr, general improvements
* more code comments
* add important note
* fix timeline tests now that timelines are returned in page order
* remove unused field
* add StatusTimeline{} tests
* add more status timeline tests
* start adding preloading support
* ensure repeat boosts are marked in preloaded entries
* share a bunch of the database load code in timeline cache, don't clear timelines on relationship change
* add logic to allow dynamic clear / preloading of timelines
* comment-out unused functions, but leave in place as we might end-up using them
* fix timeline preload state check
* much improved status timeline code comments
* more code comments, don't bother inserting statuses if timeline not preloaded
* shift around some logic to make sure things aren't accidentally left set
* finish writing code comments
* remove trim-after-insert behaviour
* fix-up some comments referring to old logic
* remove unsetting of lo, hi
* fix preload repeatBoost checking logic
* don't return on status filter errors, these are usually transient
* better concurrency safety in Clear() and Done()
* fix test broken due to addition of preloader
* fix repeatBoost logic that doesn't account for already-hidden repeatBoosts
* ensure edit submodels are dropped on cache insertion
* update code-comment to expand CAS accronym
* use a plus1hULID() instead of 24h
* remove unused functions
* add note that public / local timeline requester can be nil
* fix incorrect visibility filtering of tag timeline statuses
* ensure we filter home timeline statuses on local only
* some small re-orderings to confirm query params in correct places
* fix the local only home timeline filter func
2025-04-26 09:56:15 +00:00
|
|
|
p.surface.invalidateStatusFromTimelines(boost.BoostOfID)
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (p *fediAPI) UndoFave(ctx context.Context, fMsg *messages.FromFediAPI) error {
|
|
|
|
|
statusFave, ok := fMsg.GTSModel.(*gtsmodel.StatusFave)
|
|
|
|
|
if !ok {
|
|
|
|
|
return gtserror.Newf("%T not parseable as *gtsmodel.StatusFave", fMsg.GTSModel)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Interaction counts changed on the faved status;
|
|
|
|
|
// uncache the prepared version from all timelines.
|
|
|
|
|
p.surface.invalidateStatusFromTimelines(statusFave.StatusID)
|
2025-01-24 16:36:34 +00:00
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|