[[feature request]] - n-back links

[sneakers-the-rat]

I'll often use the anagora bot to tag one or a series of toots/tweets, but the link can relatively implicit: eg. if I am tagging someone else's toot, then what's in the agora will be my empty toot with just the link, rather than the toot/thread I'm referring to.

proposal

be able to specify n-back posts in a thread from a bridge

possible syntax

let LINK be the text of some wikilink, optionally preceded by a space

• previous toot: [[^LINK]]
• entire preceding thread: [[^*LINK]]
• previous n-toots: [[^{n}LINK]] or repeated carets, as in [[^^LINK]] for the previous 2 toots
• previous n to m toots, eg. select two to four toots above: [[^{n,m}LINK]]
• previous n toot to start of thread: [[^{n,}LINK]] or [[^{n,*}LINK]]

considerations

• restricted characters: this would make ^{,}* special characters and forbid links that start with them.
• permissions: some toots are not public, and so can't be accessed by the bot- it should reply with a warning
• consent: the preceding authors might not follow the bot, should it ask for permission? does this make sense for public posts? opt-in or opt-out? maybe an account should have the ability to "block" the bot from linking to their posts without needing to literally block the bot, I link to the threadodo bot below as an example of implementing commands.

implementation

it looks like the connectors are relatively separate, I think it would be worth standardizing the implementation of the link parser (and then having a preprocessing step to accommodate differences in sources, like stripping HTML tags, etc.) and command syntax. I'd be happy to draft that. It looks like we'd just need to update the regex currently used, and I think it would be good to make an explicit parser (eg with pyparsing or parse ) if we are adding complexity to the wikilink syntax.

Todo

threads branch! so it would be nice to be able to capture multiple branches by using the same tag from multiple tips and then make a common representation. I see currently the logs are being used as the datavase, and so along with standardizing the regexes we could make standardized data classes to represent posts and trees that can handle merging multiple links that refer to the same tree root. this would also make it possible to do n-future links, so being able to start a thread like [[*^LINK]] or [[{n}^LINK]] to capture n-depth replies.

side note: I've tried to make a general-purpose bot with extensible commands here that is a very early sketch but might be useful- https://github.com/sneakers-the-rat/threadodo

[sneakers-the-rat]

lmk if you're interested in this, I'd be happy to draft a PR

[flancian]

Ahoy there! Thank you for your patience, I really need to improve my bug tracking workflows :)

This sounds great! I've wanted this several times and track it as a todo (sort of) mentioning it as a "dump threads" function in a #push to [[agora bot]]. Some observations:

• We indeed need to merge common logic between at least the Twitter and Mastodon bots, ideally also Matrix. I've been working on the Twitter bot as of the last few weeks and it should now be in a much better position to do this.
  • Common logic should be: wikilink and hashtag parsing; link resolution (note we want to add support for other Agoras); opt in tracking; link and full note writing to the Agora. opt in/note writing is further ahead in the Twitter codebase, needs to be factored out into a library.
• I like ^ to signal context relevance but I get the feeling just including it once in the message should be enough; no need to have the circumflex in the link proper. This makes it easier to parse and seems sufficient for the core use case?
• I wonder if for opted in users we could also save the full context by default.

[sneakers-the-rat]

Here's an implementation of n-back link parsing: https://git.jon-e.net/jonny/wiki-postbot/src/commit/8d2b92e3195a95160cce6adb38f270545ee451fd/wiki_postbot/patterns/wikilink.py

from wiki_postbot.patterns.wikilink import Wikilink

# Samples of the allowed formats
wl               = Wikilink.parse("Basic [[Wikilink]]")
wl_oneback       = Wikilink.parse("one-back [[^Wikilink]]")
wl_nback         = Wikilink.parse("Wildcard-back [[^*Wikilink]]")
wl_rangeback     = Wikilink.parse("Range-back [[^{2,5}Wikilink]]")
wl_startback     = Wikilink.parse("Start-back [[^{2,}Wikilink]]")
wl_endback       = Wikilink.parse("End-back [[^{,5}Wikilink]]")
wl_endback_short = Wikilink.parse("End-back (shorthand) [[^{6}Wikilink]]")

# And (pretty-printed) parse results:

>>> wl
[{'link': 'Wikilink'}]
>>> wl_oneback
[{'link': 'Wikilink', 'nback': {'end': 1, 'start': 1, 'wildcard': False}}]
>>> wl_nback
[{'link': 'Wikilink', 'nback': {'end': None, 'start': None, 'wildcard': True}}]
>>> wl_rangeback
[{'link': 'Wikilink', 'nback': {'end': 5, 'start': 2, 'wildcard': False}}]
>>> wl_startback
[{'link': 'Wikilink', 'nback': {'end': None, 'start': 2, 'wildcard': False}}]
>>> wl_endback
[{'link': 'Wikilink', 'nback': {'end': 5, 'start': None, 'wildcard': False}}]
>>> wl_endback_short
[{'link': 'Wikilink', 'nback': {'end': 6, 'start': None, 'wildcard': False}}]

Let's open a separate issue to talk about refactoring the bot to unify implementations :)

What I'm thinking is that having it as part of the link is a way of indicating what the link refers to. The base case is when I am tagging someone else's post, i'll reply to something with a wikilink in it, but it's not my post that I want to include, it's the one above it. But it could also be the case that I want to come along and make a bunch of links with different pieces of a thread. That would be really nice to be able to do from a single reply, like [[^{2,5} Topic 1]] [[^{5,7} Topic 2]] [[^*MainTopic]] I see it as a way of being more specific about which parts of a thread/context actually pertain to a particular topic.

I can see either of the other two alternatives: not having them (context is inferred by reader), or preserving all context by default (context has to be parsed by reader) but with a parser in hand I feel like it's straightforward enough syntax to use :)