Conditional posting by self-favouriting

xurizaemon commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

I have been bouncing toots/tweets back and forth (@xurizaemon@toot.cafe || @xurizaemon@twitter.com) 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 commented 5 years ago

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 commented 2 years ago

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

FedStoa / moa

Conditional posting by self-favouriting #108