Learn to use email with git! Patch Workflows - Ry’s Git Tutorial - RyPress – Another good blog post on working with Git patches via Email as well as applying them. – The key point (I think) is that you need to grab the entire contents of email email in order in order to pipe the contents into git am - – Hmmm 🤔 – I think we can do better than this…

@prologic@twtxt.net 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?

@prologic@twtxt.net Oh, cool and the feed is in the repo so you can host it together?

Things like git-notes might work with it?

@prologic@twtxt.net maybe keeping the management in git and using emails just for notification could be better?

@prologic@twtxt.net so a web UI is the only way (or a cli version that act similarly)?

@prologic@twtxt.net 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@twtxt.net 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?)

@prologic@twtxt.net 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.

@prologic@twtxt.net 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.

@prologic@twtxt.net 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.

@prologic@twtxt.net 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.

@prologic@twtxt.net 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@twtxt.net this would allow super flexible extensions, good going!👌

@prologic@twtxt.net sure, I’m going to make a static mock of the interface from scratch, while thinking on the general features we’ve talked about.