# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 36
# self = https://watcher.sour.is/conv/7u2cl6a
@prologic interesting. I'm not really a fan of the conventions this tool uses. So many files and subdirectories, and conventions to convert filenames to human-readable content. So much clutter and mixed concerns in the git history.
I think if I had to use this I'd make a separate project for issues corresponding to each project so that the project commits are just about code and not mixed up with commits about issue-related files.
@abucci Hmmm you raise a good point 👌 Signal/Noise is important in any design and I tend to agree here with you. Makes git-bug far more appealing in that regard because of the way it stores data...
@abucci Hmmm you raise a good point 👌 Signal/Noise is important in any design and I tend to agree here with you. Makes git-bug far more appealing in that regard because of the way it stores data...
@abucci Hmmm you raise a good point 👌 Signal/Noise is important in any design and I tend to agree here with you. Makes git-bug far more appealing in that regard because of the way it stores data...
@abucci Hmmm you raise a good point 👌 Signal/Noise is important in any design and I tend to agree here with you. Makes git-bug far more appealing in that regard because of the way it stores data...
@prologic it's possible to store any missing data using the git-bug approach to add any missing functionality to a git repo without relying on external data storage, can't we?
@justamoment I _think_, at least that's the idea, and it _allegedly_ doesn't pollute the actual repo with unrelated files (I don't think) -- I still haven't been able to get it to work locally though so hoping someone will answer my comment on the issue. But yeah depending on how git-bug evolves over time we _could_ just integrate with it "somehow"
@justamoment I _think_, at least that's the idea, and it _allegedly_ doesn't pollute the actual repo with unrelated files (I don't think) -- I still haven't been able to get it to work locally though so hoping someone will answer my comment on the issue. But yeah depending on how git-bug evolves over time we _could_ just integrate with it "somehow"
@justamoment I _think_, at least that's the idea, and it _allegedly_ doesn't pollute the actual repo with unrelated files (I don't think) -- I still haven't been able to get it to work locally though so hoping someone will answer my comment on the issue. But yeah depending on how git-bug evolves over time we _could_ just integrate with it "somehow"
@justamoment I _think_, at least that's the idea, and it _allegedly_ doesn't pollute the actual repo with unrelated files (I don't think) -- I still haven't been able to get it to work locally though so hoping someone will answer my comment on the issue. But yeah depending on how git-bug evolves over time we _could_ just integrate with it "somehow"
@prologic I see, pretty cool.
But personally I prefer the file based approach though, you have a friendly folder that lets you open anyway you want without fiddling the repo, you can use a separate repo if you don't like it in the source and everything is tracked in the same way without having to manual dig in them if you don't want to use a given tool.
This is one that could be a better solution if you like that approach too: https://github.com/dspinellis/git-issue
Being file based also let you build a "protocol" on it that can be detached from the repo in itself and let you manage it in a similar fashion of twtxt.
What do you think?
@justamoment Yeah that's another pretty similar way of doing the same thing I guess? Basically a bunch of files in the same repo in even a separate repo right? 🤔
@justamoment Yeah that's another pretty similar way of doing the same thing I guess? Basically a bunch of files in the same repo in even a separate repo right? 🤔
@justamoment Yeah that's another pretty similar way of doing the same thing I guess? Basically a bunch of files in the same repo in even a separate repo right? 🤔
@justamoment Yeah that's another pretty similar way of doing the same thing I guess? Basically a bunch of files in the same repo in even a separate repo right? 🤔
@justamoment I'm still _thinking_ about how we can make Git + Twtxt work in a way that is a sort-of "socialised" collaboration of a Git repo's issues and reviews of patches... 😅
@justamoment I'm still _thinking_ about how we can make Git + Twtxt work in a way that is a sort-of "socialised" collaboration of a Git repo's issues and reviews of patches... 😅
@justamoment I'm still _thinking_ about how we can make Git + Twtxt work in a way that is a sort-of "socialised" collaboration of a Git repo's issues and reviews of patches... 😅
@justamoment I'm still _thinking_ about how we can make Git + Twtxt work in a way that is a sort-of "socialised" collaboration of a Git repo's issues and reviews of patches... 😅
@prologic "Git.social" then! 😎
Git "pods" with "repos", "issue" and "review" feeds.
Every changes on a repo is notified in a repos feed.
Each issue or review is a file in a folder with an hash and people can reply on the conversation, or at least the "notification" of it in their feed.
A nice approach I saw in Trello, you can email a card ID and it get embedded in the card, it can be done here too on the file, as to not have everything spread on hundreds of feeds.
Working like this you can integrate twtxt but not rely on it entirely, letting users use it without it, I'd see this as generic integration though, so other can add more "bridges" (like in git-bug) to their liking.
How is it?
@prologic "Git.social" then! 😎
Git "pods" with "repos", "issue" and "review" feeds.
Every changes on a repo is notified in a repos feed.
Each issue or review is a file in a folder with an hash and people can reply on the conversation, or at least the "notification" of it in their feed.
A nice approach I saw in Trello, you can email a card ID and it get embedded in the card, it can be done here too on the file, as to not have everything spread on hundreds feeds.
Working like this you can integrate text but not rely on it entirely, letting users use it without it, I'd see this as generic integration though, so other can add more "bridges" (like in git-bug) to their liking.
How it's it?
@prologic "Git.social" then! 😎
Git "pods" with "repos", "issue" and "review" feeds.
Every changes on a repo is notified in a repos feed.
Each issue or review is a file in a folder with an hash and people can reply on the conversation, or at least the "notification" of it in their feed.
A nice approach I saw in Trello, you can email a card ID and it get embedded in the card, it can be done here too on the file, as to not have everything spread on hundreds of feeds.
Working like this you can integrate twtxt but not rely on it entirely, letting users use it without it, I'd see this as generic integration though, so other can add more "bridges" (like in git-bug) to their liking.
How it's it?
Too bad git.social is taken 😅 It would have made a great domain and project name, but you are on to something 😍
Too bad git.social is taken 😅 It would have made a great domain and project name, but you are on to something 😍
Too bad git.social is taken 😅 It would have made a great domain and project name, but you are on to something 😍
Too bad git.social is taken 😅 It would have made a great domain and project name, but you are on to something 😍