# 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 73
# self = https://watcher.sour.is/conv/fovxkya
@prologic This patch workflow looks complicated for no reason to me, it also leave everything to a maintainer to handle privately before touching the public repo.
Maybe a branch based approach like the one used in GitHub/Lab/tea is simpler but still doable? Maybe as part for legit fork?
@justamoment I agree, the patch workflow is a bit complicated (_especially for new users_) and I find it a bit unfriendly too. Having to switch from an Email client to Command-line just to manage reviews and applying patches kind of sucks IMO. -- Some nice way to manage incoming changes and communicate reviews and easily applying those changes would be nicer. -- I even had this stupid idea of pushing patches to a special endpoint that create a new Twt in a per-repo Twtxt feed with a link to the "patch" (via a Web UI) and then you can communicate feedback over your own feeds π€£ -- Finally a "patch" is either #approved or #rejected and patch manager can look for those tags in the thread and deal with the UI appropriately.
@justamoment I agree, the patch workflow is a bit complicated (_especially for new users_) and I find it a bit unfriendly too. Having to switch from an Email client to Command-line just to manage reviews and applying patches kind of sucks IMO. -- Some nice way to manage incoming changes and communicate reviews and easily applying those changes would be nicer. -- I even had this stupid idea of pushing patches to a special endpoint that create a new Twt in a per-repo Twtxt feed with a link to the "patch" (via a Web UI) and then you can communicate feedback over your own feeds π€£ -- Finally a "patch" is either #approved or #rejected and patch manager can look for those tags in the thread and deal with the UI appropriately.
@justamoment I agree, the patch workflow is a bit complicated (_especially for new users_) and I find it a bit unfriendly too. Having to switch from an Email client to Command-line just to manage reviews and applying patches kind of sucks IMO. -- Some nice way to manage incoming changes and communicate reviews and easily applying those changes would be nicer. -- I even had this stupid idea of pushing patches to a special endpoint that create a new Twt in a per-repo Twtxt feed with a link to the "patch" (via a Web UI) and then you can communicate feedback over your own feeds π€£ -- Finally a "patch" is either #approved or #rejected and patch manager can look for those tags in the thread and deal with the UI appropriately.
@justamoment I agree, the patch workflow is a bit complicated (_especially for new users_) and I find it a bit unfriendly too. Having to switch from an Email client to Command-line just to manage reviews and applying patches kind of sucks IMO. -- Some nice way to manage incoming changes and communicate reviews and easily applying those changes would be nicer. -- I even had this stupid idea of pushing patches to a special endpoint that create a new Twt in a per-repo Twtxt feed with a link to the "patch" (via a Web UI) and then you can communicate feedback over your own feeds π€£ -- Finally a "patch" is either #approved or #rejected and patch manager can look for those tags in the thread and deal with the UI appropriately.
@prologic Oh, cool and the feed is in the repo so you can host it together?
Things like git-notes might work with it?
@prologic maybe keeping the management in git and using emails just for notification could be better?
@justamoment Hmmm so there isn't a lot you can do with plain Git itself. Even patches sent via email are basisally out-or-band at that point.
@justamoment Hmmm so there isn't a lot you can do with plain Git itself. Even patches sent via email are basisally out-or-band at that point.
@justamoment Hmmm so there isn't a lot you can do with plain Git itself. Even patches sent via email are basisally out-or-band at that point.
@justamoment Hmmm so there isn't a lot you can do with plain Git itself. Even patches sent via email are basisally out-or-band at that point.
@prologic so a web UI is the only way (or a cli version that act similarly)?
@justamoment Well what I mean to say is that git itself basically just houses some client-side "Metadata" about the repository and a bunch of objects that make up the contents and revision history. For example, there is a special file called .git/description that you can edit and there's even git branch --edit to edit a branch's description. But none of that is useful beyond a local client. That is to say, if you git clone or git push none of that information is published anywhere or made available to anyone else.
So Git's "distributed data" is limited to well basically its revision history and series of objects I guess? π€
@justamoment Well what I mean to say is that git itself basically just houses some client-side "Metadata" about the repository and a bunch of objects that make up the contents and revision history. For example, there is a special file called .git/description that you can edit and there's even git branch --edit to edit a branch's description. But none of that is useful beyond a local client. That is to say, if you git clone or git push none of that information is published anywhere or made available to anyone else.
So Git's "distributed data" is limited to well basically its revision history and series of objects I guess? π€
@justamoment Well what I mean to say is that git itself basically just houses some client-side "Metadata" about the repository and a bunch of objects that make up the contents and revision history. For example, there is a special file called .git/description that you can edit and there's even git branch --edit to edit a branch's description. But none of that is useful beyond a local client. That is to say, if you git clone or git push none of that information is published anywhere or made available to anyone else.
So Git's "distributed data" is limited to well basically its revision history and series of objects I guess? π€
@justamoment Well what I mean to say is that git itself basically just houses some client-side "Metadata" about the repository and a bunch of objects that make up the contents and revision history. For example, there is a special file called .git/description that you can edit and there's even git branch --edit to edit a branch's description. But none of that is useful beyond a local client. That is to say, if you git clone or git push none of that information is published anywhere or made available to anyone else.
So Git's "distributed data" is limited to well basically its revision history and series of objects I guess? π€
@prologic But if we edit those on a remote repo then we can use it as a public description and when cloned you don't need to care for it, right?
@prologic But if we edit those on a remote repo then we can use it as a public description and when cloned you don't need to case for it, right?
@justamoment Yup pretty much. That's what I'm thinking here... So the Web UI we build need to support IndieAuth I _think_ (well it would be nice if it did I think) so we can manage repos... Repo descriptions can be stored/retrieved from .git/description -- Likewise we can probably do something with SSH keys like storing the keys permitted for "write" access in .git/authorized_keys. What else? Hmmm π€
@justamoment Yup pretty much. That's what I'm thinking here... So the Web UI we build need to support IndieAuth I _think_ (well it would be nice if it did I think) so we can manage repos... Repo descriptions can be stored/retrieved from .git/description -- Likewise we can probably do something with SSH keys like storing the keys permitted for "write" access in .git/authorized_keys. What else? Hmmm π€
@justamoment Yup pretty much. That's what I'm thinking here... So the Web UI we build need to support IndieAuth I _think_ (well it would be nice if it did I think) so we can manage repos... Repo descriptions can be stored/retrieved from .git/description -- Likewise we can probably do something with SSH keys like storing the keys permitted for "write" access in .git/authorized_keys. What else? Hmmm π€
@justamoment Yup pretty much. That's what I'm thinking here... So the Web UI we build need to support IndieAuth I _think_ (well it would be nice if it did I think) so we can manage repos... Repo descriptions can be stored/retrieved from .git/description -- Likewise we can probably do something with SSH keys like storing the keys permitted for "write" access in .git/authorized_keys. What else? Hmmm π€
@prologic What are the functionality we need?
I can see those:
- hosting
- bug tracking
- code reviews
- forking (i guess?)
- SSH
- push / pull (it's read only now, right?)
@justamoment I guess we start with:
- An interface to manager repos
- Support for git push over SSH with key management
What already works (mostly):
- Hosting
- Cloning via git clone over HTTP/SSH
What still needs consideration/experimentation:
- Code reviews
- Issue tracking
@justamoment I guess we start with:
- An interface to manager repos
- Support for git push over SSH with key management
What already works (mostly):
- Hosting
- Cloning via git clone over HTTP/SSH
What still needs consideration/experimentation:
- Code reviews
- Issue tracking
@justamoment I guess we start with:
- An interface to manager repos
- Support for git push over SSH with key management
What already works (mostly):
- Hosting
- Cloning via git clone over HTTP/SSH
What still needs consideration/experimentation:
- Code reviews
- Issue tracking
@justamoment I guess we start with:
- An interface to manager repos
- Support for git push over SSH with key management
What already works (mostly):
- Hosting
- Cloning via git clone over HTTP/SSH
What still needs consideration/experimentation:
- Code reviews
- Issue tracking
@prologic ok, for interface what do you mean exactly? Are you talking about editing the repo?
About the web interface, I'd suggest to use REST API as the main interface regardless of where it's built, so you can use them both on client and server side with the same data structure and available actions.
For the client side of any external scripting or custom web clients you have pure data to work with, if on the server side you have the same structs to build the HTML.
This helps us avoid having to work on both in parallel like with Yarn.social and leaving one side behind the other.
@justamoment Can we still maintain a nice SSR (Server-side Rendered) UI though? This is something I _never_ quite managed to "get right", it would be nice to not have any Javascript (or ever little) for the UI but to still power the SSR and API with the same data structures (which is what I think you're talking about?)
@justamoment Can we still maintain a nice SSR (Server-side Rendered) UI though? This is something I _never_ quite managed to "get right", it would be nice to not have any Javascript (or ever little) for the UI but to still power the SSR and API with the same data structures (which is what I think you're talking about?)
@justamoment Can we still maintain a nice SSR (Server-side Rendered) UI though? This is something I _never_ quite managed to "get right", it would be nice to not have any Javascript (or ever little) for the UI but to still power the SSR and API with the same data structures (which is what I think you're talking about?)
@justamoment Can we still maintain a nice SSR (Server-side Rendered) UI though? This is something I _never_ quite managed to "get right", it would be nice to not have any Javascript (or ever little) for the UI but to still power the SSR and API with the same data structures (which is what I think you're talking about?)
@prologic exactly, exposed as a struct and functions (for actions) in a dedicated layer, then the API would have GET from structs and POST for functions, on server you render html the same way, structs in templates and POST for actions.
A way to have them seamlessly would be to handle the same page with content-type but maybe it's an overkill for this kind of project.
@justamoment Yeah I have a few ideas for how to structure this, but I've never seen anyone do it, probably because these days everyone just does this React shitβ’ π€£ Gotta give this a try though... π€
@justamoment Yeah I have a few ideas for how to structure this, but I've never seen anyone do it, probably because these days everyone just does this React shitβ’ π€£ Gotta give this a try though... π€
@justamoment Yeah I have a few ideas for how to structure this, but I've never seen anyone do it, probably because these days everyone just does this React shitβ’ π€£ Gotta give this a try though... π€
@justamoment Yeah I have a few ideas for how to structure this, but I've never seen anyone do it, probably because these days everyone just does this React shitβ’ π€£ Gotta give this a try though... π€
@prologic actually with next.js it does that on the server but it's not quite what I'm thinking, you should find examples on cli apps for remote services or modular projects with the server side UI as a separate component.
@justamoment Yup π I'm going to experiment on someyhing a bit contrived add aee what pattern I can come up with π€
@justamoment Yup π I'm going to experiment on someyhing a bit contrived add aee what pattern I can come up with π€
@justamoment Yup π I'm going to experiment on someyhing a bit contrived add aee what pattern I can come up with π€
@justamoment Yup π I'm going to experiment on someyhing a bit contrived add aee what pattern I can come up with π€
@prologic what I recommend is a dedicated layer for data fetching and manipulation, and call it from where you need it.
By simply serializing the data via API and as raw data on server templates.
@justamoment So, we'll build a few data models that represents data we need to store and mutate and some logic to fetch that data and perform actions on it. Then an API layer will use that and serialise as either a JSON RPC API or JSON Rest API. Another layer will call the same code to fill out template contexts and render templates. Does this sound about right? π€
@justamoment So, we'll build a few data models that represents data we need to store and mutate and some logic to fetch that data and perform actions on it. Then an API layer will use that and serialise as either a JSON RPC API or JSON Rest API. Another layer will call the same code to fill out template contexts and render templates. Does this sound about right? π€
@justamoment So, we'll build a few data models that represents data we need to store and mutate and some logic to fetch that data and perform actions on it. Then an API layer will use that and serialise as either a JSON RPC API or JSON Rest API. Another layer will call the same code to fill out template contexts and render templates. Does this sound about right? π€
@justamoment So, we'll build a few data models that represents data we need to store and mutate and some logic to fetch that data and perform actions on it. Then an API layer will use that and serialise as either a JSON RPC API or JSON Rest API. Another layer will call the same code to fill out template contexts and render templates. Does this sound about right? π€
@prologic that's right, do you call the JSON RPC from the server rendering or directly from a middle layer (to keep in go) I see both as good.
@prologic that's right, do you call the JSON RPC from the server rendering or directly from a middle layer (to keep in Go) I see both as good.
@prologic that's right, do you call the JSON RPC from the server rendering or directly from a middle layer (to keep in Go)? I see both as good.
@justamoment Yeah I'm kind of thinking that the JSON API / REST API + SSR Templating calls a "middle" layer. In other words, abstract out the actual data handling and logic with interfaces that can be used for a real response directly (content negotiated) or rendered with some HTML templates.
@justamoment Yeah I'm kind of thinking that the JSON API / REST API + SSR Templating calls a "middle" layer. In other words, abstract out the actual data handling and logic with interfaces that can be used for a real response directly (content negotiated) or rendered with some HTML templates.
@justamoment Yeah I'm kind of thinking that the JSON API / REST API + SSR Templating calls a "middle" layer. In other words, abstract out the actual data handling and logic with interfaces that can be used for a real response directly (content negotiated) or rendered with some HTML templates.
@justamoment Yeah I'm kind of thinking that the JSON API / REST API + SSR Templating calls a "middle" layer. In other words, abstract out the actual data handling and logic with interfaces that can be used for a real response directly (content negotiated) or rendered with some HTML templates.
@prologic this would allow super flexible extensions, good going!π
@justamoment Cooool, so now I just gotta iterate on a few patterns and see what works best and get your opinion on it π
@justamoment Cooool, so now I just gotta iterate on a few patterns and see what works best and get your opinion on it π
@justamoment Cooool, so now I just gotta iterate on a few patterns and see what works best and get your opinion on it π
@justamoment Cooool, so now I just gotta iterate on a few patterns and see what works best and get your opinion on it π
@prologic sure, I'm going to make a static mock of the interface from scratch, while thinking on the general features we've talked about.