使用Golang构建P2P Git门户（GitHub替代方案）

使用Golang构建P2P Git门户（GitHub替代方案） 我正在开发一个去中心化的GitHub替代方案（即无需服务器和第三方），并欢迎任何对此感兴趣的Golang开发者参与协助。

该项目旨在构建一个基于静态HTML的Web风格应用，使其能在浏览器中运行，从而无需服务器或服务器端处理。该应用可以部署在静态Web托管服务上，或者更好地部署在P2P存储或IPFS上，或者最便捷的方式是利用Safe Network的去中心化特性来处理授权和防止垃圾问题。因此，虽然我将以Safe Network为目标，但若能与其他开发者合作，基于相同的方法和核心为IPFS或DAT等平台开发解决方案，那将非常棒。

我已经确定了一条可能的实现路径：将go-git/go-billy编译为WASM（我相信这已经可行），同时结合git-bug（这需要更多工作——详见下文）以及一个Svelte前端。

目前，我已经搭建了大部分框架，因此相当有信心能够构建一个可用的概念验证。不过，我非常希望能得到一些帮助来加快进度，因为我认为这是一个非常有价值的项目，并且从网上的反馈来看，许多人会对使用它感兴趣。

如果您想关注进展，概念验证将随着开发的推进发布在GitHub上：

GitHub GitHub

happybeing/p2p-git-portal-poc

p2p git portal proof-of-concept using Svelte Golang/WASM (experimental) - happybeing/p2p-git-portal-poc

如果您有兴趣提供帮助，请查看以下问题：

  • Golang：使git-bug可作为包使用（参见问题）
  • Golang：使git-bug使用go-billy文件系统（参见问题）
  • Svelte/HTML/CSS：创建适合Git门户的样式（参见问题）

更多关于使用Golang构建P2P Git门户（GitHub替代方案）的实战教程也可以访问 https://www.itying.com/category-94-b0.html

1 回复

更多关于使用Golang构建P2P Git门户（GitHub替代方案）的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


这是一个非常雄心勃勃且技术前沿的项目。将Git和Bug追踪系统完全去中心化，并运行在浏览器环境中，这直接挑战了当前中心化代码托管平台的范式。以下是我对您技术路径和当前需求的分析与建议：

1. 核心架构评估

您选择的go-git + go-billy + WASM + Svelte的技术栈是合理的：

  • go-git：纯Go实现的Git，编译为WASM后能在浏览器中执行完整的Git操作（clone, commit, push, pull等）。
  • go-billy：抽象文件系统接口，这是关键所在。在浏览器中，您需要通过go-billy适配到浏览器的虚拟文件系统（如BrowserFS）或IndexedDB。
  • git-bug：基于Git的分布式Bug追踪，与您的去中心化理念完美契合。

2. 对您列出的Golang问题的具体分析

问题1: 使git-bug可作为包使用

当前git-bug更像一个独立应用。要将其作为库使用，需要：

  • 暴露清晰的API接口。
  • 减少或可配置化全局状态和副作用。
  • 示例：封装核心的Bug操作。
// 理想中的API示例
package gitbug

import (
    "context"
    "io"
)

type BugManager struct {
    repo *git.Repository
    // ... 其他依赖
}

func NewBugManager(repoPath string) (*BugManager, error) {
    // 初始化git仓库和git-bug
}

func (bm *BugManager) CreateBug(title, message string) (BugID, error) {
    // 创建新Bug
}

func (bm *BugManager) ListBugs() ([]BugSummary, error) {
    // 列出所有Bug
}

// 使git-bug的命令行操作转化为方法调用

问题2: 使git-bug使用go-billy文件系统

git-bug当前可能直接使用操作系统文件系统。需要将其改为依赖go-billy.Filesystem接口。

// 修改git-bug内部的文件访问
// 原始可能为 os.Open(filePath)
// 需改为 fs.Open(filePath) ，其中fs是go-billy.Filesystem

// 在初始化时注入文件系统
func NewBugManagerWithFS(fs billy.Filesystem) (*BugManager, error) {
    // 使用传入的fs进行所有文件操作
    repo, err := git.InitWithOptions(fs, &git.InitOptions{...})
    // ...
}

3. WASM编译与浏览器集成的关键点

将go-git和git-bug编译为WASM时需要注意：

// main_wasm.go 示例
package main

import (
    "syscall/js"
    git "github.com/go-git/go-git/v5"
    billy "github.com/go-git/go-billy/v5"
    browserfs "github.com/jvilk/browserfs" // 假设的BrowserFS绑定
)

func cloneRepo(this js.Value, args []js.Value) interface{} {
    // 从JS获取参数
    url := args[0].String()
    
    // 初始化浏览器文件系统
    fs := browserfs.NewFS()
    
    // 使用go-git克隆仓库
    _, err := git.PlainCloneWithOptions(fs, "/repo", &git.CloneOptions{
        URL: url,
    })
    
    // 返回Promise给JS
    promise := js.Global().Get("Promise")
    // ... 处理异步结果
}

func main() {
    // 暴露函数给JavaScript
    js.Global().Set("goGit", map[string]interface{}{
        "clone": js.FuncOf(cloneRepo),
    })
    
    // 保持WASM模块运行
    select {}
}

4. P2P存储集成考虑

对于Safe Network/IPFS/DAT的集成，建议抽象存储层：

// 存储接口抽象
type P2PStorage interface {
    Read(key string) ([]byte, error)
    Write(key string, data []byte) error
    Delete(key string) error
}

// 不同的实现
type SafeNetworkStorage struct {
    // Safe Network客户端
}

type IPFSStorage struct {
    // IPFS客户端
}

// git-bug和go-git通过此接口访问存储，而非直接文件系统

5. 性能与限制提醒

  • WASM二进制大小：go-git + git-bug的WASM可能较大，需要关注加载时间和分包加载。
  • 浏览器存储限制：IndexedDB通常有每个域名存储上限（约5GB），大型仓库可能受限。
  • P2P网络延迟：完全去中心化下，克隆/推送操作可能比中心化服务器慢。

6. 建议的下一步开发重点

  1. 最小可行产品(MVP)路径：

    • 先实现基于IndexedDB的纯浏览器内版本
    • 再添加IPFS/Safe Network的P2P存储后端
    • 最后处理身份验证和垃圾防护

  2. 模块化设计：

// 核心模块划分
- Core (go-git + git-bug WASM)
- Storage Adapter (IndexedDB/IPFS/Safe Network)
- Frontend Bridge (JS/WASM互操作)
- UI (Svelte组件)

这个项目如果成功，将为完全去中心化的开源协作树立新的技术标杆。您已经识别了正确的技术组件，现在需要的是将这些组件优雅地集成并解决边界情况。期待看到您的概念验证进展！

回到顶部