# 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 25
# self = https://watcher.sour.is/conv/jieuh3q
@prologic and @justamoment, this Gitxt project sounds really interesting. Can you tell us about some of your goals?
More specifically: Will this be expanded into something like Gitea with the concept of users and organizations, or will it stay with a simple flat repository model like upstream legit or cgit?
Also, the shorthand mention syntax has struck again. Apologies, @justamoment.
@mckinley That's a great question actually. Should we go for multi-user and org/user? Or keep it simple? 🤔 What are you thinking here? 🤔
@mckinley That's a great question actually. Should we go for multi-user and org/user? Or keep it simple? 🤔 What are you thinking here? 🤔
@mckinley That's a great question actually. Should we go for multi-user and org/user? Or keep it simple? 🤔 What are you thinking here? 🤔
@mckinley That's a great question actually. Should we go for multi-user and org/user? Or keep it simple? 🤔 What are you thinking here? 🤔
I _think_ if we did support multi-user / multi-org, it would have to be kept deliberately rather simple. That is, it acts basically like a group of repositories and nothing more. Access tokens/keys would still be stored in (for example) .git/authorized_keys or .git/authorized_tokens
I _think_ if we did support multi-user / multi-org, it would have to be kept deliberately rather simple. That is, it acts basically like a group of repositories and nothing more. Access tokens/keys would still be stored in (for example) .git/authorized_keys or .git/authorized_tokens
I _think_ if we did support multi-user / multi-org, it would have to be kept deliberately rather simple. That is, it acts basically like a group of repositories and nothing more. Access tokens/keys would still be stored in (for example) .git/authorized_keys or .git/authorized_tokens
I _think_ if we did support multi-user / multi-org, it would have to be kept deliberately rather simple. That is, it acts basically like a group of repositories and nothing more. Access tokens/keys would still be stored in (for example) .git/authorized_keys or .git/authorized_tokens
OTOH if we continued to abstract out more of yarnd's codebase, in theory we _could_ basically have a social Git forge/hosting solution that basically uses Twtxt everywhere, including Profiles for Orgs/Users (think Twtxt feed preamble/metadata) and you could follow orgs and users as well as repo logs (or should that be a specialised feed like repo events taht contain things like commit events, merge-request events, etc?)
OTOH if we continued to abstract out more of yarnd's codebase, in theory we _could_ basically have a social Git forge/hosting solution that basically uses Twtxt everywhere, including Profiles for Orgs/Users (think Twtxt feed preamble/metadata) and you could follow orgs and users as well as repo logs (or should that be a specialised feed like repo events taht contain things like commit events, merge-request events, etc?)
OTOH if we continued to abstract out more of yarnd's codebase, in theory we _could_ basically have a social Git forge/hosting solution that basically uses Twtxt everywhere, including Profiles for Orgs/Users (think Twtxt feed preamble/metadata) and you could follow orgs and users as well as repo logs (or should that be a specialised feed like repo events taht contain things like commit events, merge-request events, etc?)
OTOH if we continued to abstract out more of yarnd's codebase, in theory we _could_ basically have a social Git forge/hosting solution that basically uses Twtxt everywhere, including Profiles for Orgs/Users (think Twtxt feed preamble/metadata) and you could follow orgs and users as well as repo logs (or should that be a specialised feed like repo events taht contain things like commit events, merge-request events, etc?)
@prologic
> Should we go for multi-user and org/user? Or keep it simple?
I really don't know which would be better.
You would need user accounts for issues and to facilitate collaboration, unless you used e-mail, which isn't really a bad thing. The SourceHut model works very well.
No matter what, I would love to be able to archive issues using Git alone. You were talking about integrating git-bug or something similar, and I think that's an excellent idea.
@mckinley I'd really like to see if we can make Git + Twtxt work 😆
That is, fully decentralized issues, patches and reviews and of course code!
@mckinley I'd really like to see if we can make Git + Twtxt work 😆
That is, fully decentralized issues, patches and reviews and of course code!
@mckinley I'd really like to see if we can make Git + Twtxt work 😆
That is, fully decentralized issues, patches and reviews and of course code!
@mckinley I'd really like to see if we can make Git + Twtxt work 😆
That is, fully decentralized issues, patches and reviews and of course code!
Plain text files for the win! 😆
Plain text files for the win! 😆
Plain text files for the win! 😆
Plain text files for the win! 😆
@prologic for what I see, this should be handled at a repo level and it should be handled in a file based fashion for everything to me.
Organizations and users can simply be folders with a top level repo that handle their "metadata".
If we keep everyone on one level, then they can simply be #ORG or @user referenced in the feed.
Also what I'd like is to keep everything decoupled from the tool, if one wants to contribute manually without using any tools I'd love to see them do as much with no problems.
@mckinley also when you reference me like this it becomes external and I can't see the mention in my list...