@prologic@twtxt.net 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@twtxt.net.
@mckinley@twtxt.net 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
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?)
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@twtxt.net 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! 😆
@prologic@twtxt.net 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@twtxt.net also when you reference me like this it becomes external and I can’t see the mention in my list…