Conditional posting by self-favouriting

[xurizaemon]

I would like to have "opt-in" sync so that toots are not relayed unless I also fave them.

This would be a trivial and accessible way to manage reposting.

[xurizaemon]

Thinking about how to implement this. Haven't yet got dev instance running.

• if polling for "latest toot", and capture toot before it's faved, we miss the toot getting faved
• ideally don't want to have to poll and store faves as well, but may need to
• if mastodon API allows fetching toots with criteria (user=123 and faved_by=123) that might work to prevent fetching as yet unfaved toots, not confident this is an option
• may need to store faves (self-faved only?) then in order to do this

[xurizaemon]

I see #77 implements a very similar functionality. That's cool but it's not what I want to deliver here.

To me the hashtag approach (including the metadata in the post) "dirties" your preferred / primary network with references to the secondary. I want to post to my preferred network and mostly forget about the other, so the last thing I want to do is to include a hashtag mentioning the other network (whether opting in or out).

Self-faving is an unobtrusive and subtle and it's true you should favourite your own toots/tweets.

[foozmeat]

@xurizaemon I was looking over your PR yesterday and the way its written I believe that any fav, not just a self-fav, would cause the message to be cross-posted. I'm going to hold off on merging until I can dig into it more.

[xurizaemon]

I have been bouncing toots/tweets back and forth (@[email protected] || @[email protected]) and haven't observed that behaviour - though I could easily miss things on my own timeline.

Is it possible that it would affect only any fav of an account which is currently being tracked by the moa.party instance in question, which means even with 1-2000 moa.party accounts the odds of a dupe would be small.

Since my forked moa.party instance tracks only my and a test account, I wouldn't easily observe that behaviour (if it's also dependent on crossposting a faved account from another moa.party user) though.

There are other things which leave this at WIP for me, eg not sure how you'd like to tackle the naming of "conditional_posting" vs "conditional posting via faves" or whatever I'd called it. I did look into SQLAlchemy migrations but wasn't sure how to "secure" a commit hash for the migration, do you just use the parent commit? That seemed weird. Anyway, this paragraph is to say I also think it's WIP, even though I'm happy using it in present state.

[foozmeat]

The Flask-migrate package support generating the migrations automatically with the flask migrate and flask upgrade commands. I have a shell script in tools to make running it easier.

I'll dig into the issue more deeply and figure it out.

[xurizaemon]

I've re-opened this at https://gitlab.com/fedstoa/moa/-/issues/53 (issue).