Skip to content

Instantly share code, notes, and snippets.

View melvincarvalho's full-sized avatar
💭
I may be slow to respond.

Melvin Carvalho melvincarvalho

💭
I may be slow to respond.
View GitHub Profile
@melvincarvalho
melvincarvalho / tseed-design.md
Last active January 2, 2026 17:27
TSEED: Incentivized Torrents with Bitcoin Settlement - Design Document

TSEED: Incentivized Torrents with Bitcoin Settlement

What if seeding torrents paid real Bitcoin?


The Insight

Private trackers solved the free-rider problem with reputation. 500 million people torrent. Most content dies because no one seeds.

@melvincarvalho
melvincarvalho / git-nostr-guide.md
Last active January 1, 2026 14:22
Git with Nostr Authentication on JSS

Git with Nostr Authentication on JSS

Use git to clone and push to a JavaScript Solid Server (JSS) pod with Nostr NIP-98 authentication.

Prerequisites

  • Node.js 18+
  • JSS server running with --git flag (or "git": true in config)
  • Git installed
@melvincarvalho
melvincarvalho / git-support.md
Created January 1, 2026 10:33
Adding Git HTTP Backend Support to a Solid Server

Adding Git Support to a Solid Server

This guide explains how to add Git HTTP backend support to a Solid server, enabling git clone and git push operations on pod containers.

Overview

The Git HTTP protocol allows clients to clone and push to repositories over HTTP. This is implemented using Git's built-in git http-backend CGI program - the same one used by Apache and Nginx.

How It Works

@melvincarvalho
melvincarvalho / nip-content-rendering.md
Last active December 27, 2025 11:07
NIP-XX: Content Rendering Guidelines - Standardizing media URL detection across Nostr clients

NIP-XX

Content Rendering Guidelines

draft optional

This NIP defines standard guidelines for how clients SHOULD detect and render inline media URLs and other embeddable content within event .content fields. The goal is to provide a consistent user experience across different Nostr clients.

@melvincarvalho
melvincarvalho / opreturncve.md
Created November 18, 2025 21:41
opreturncve.md

CVE-20XX-XXXX: Bitcoin Core OP_RETURN Arbitrary Data Exposure via Self-Rendering Payloads

Summary

Bitcoin Core v30 and later relay, index, and expose up to 100,000 bytes of arbitrary OP_RETURN data by default. When an attacker embeds a self-rendering Data URI (e.g., data:image/*;base64,…) inside an OP_RETURN output, Bitcoin Core stores the content and makes it accessible through standard JSON-RPC and REST interfaces. Any client retrieving the transaction through these interfaces receives the Data URI in cleartext, which can be immediately rendered by a web browser or other HTTP-capable software without specialized tooling.

This behavior may unintentionally cause node operators to store, retrieve, or serve content that is harmful, illegal, or high-risk, creating operational, security, and legal exposure for downstream systems.

Vulnerability Type

@melvincarvalho
melvincarvalho / RGBNIA1.md
Created September 10, 2025 10:36
RGBNIA1.md

RGB Contract Encoding and Commitment Analysis

Executive Summary

This document provides a detailed analysis of how RGB Non-Inflatable Assets (NIA) are encoded, hashed, and committed to Bitcoin using the RGB protocol. The analysis is based on the issue_nia::case_1 test executi on.


Test Parameters

@melvincarvalho
melvincarvalho / baid64.md
Created September 4, 2025 21:36
baid64.md

Baid64 Specification

Overview

Baid64 (Base64 Aided Identities) is an enhanced Base64 encoding scheme designed for secure, human-verifiable identity encoding. It extends standard Base64 with Human Readable Identifiers (HRI), cryptographic check sums, mnemonic representations, and optional formatting features to create a robust encoding system suitable for identity management and secure data representation.

Core Components

1. Custom Alphabet

@melvincarvalho
melvincarvalho / bookmark.jsonld
Last active June 29, 2025 18:29
bookmark.jsonld
{
"@context": {
"bookmark": "https://w3id.org/bookmark#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"schema": "https://schema.org/",
"dct": "http://purl.org/dc/terms/",
"xsd": "http://www.w3.org/2001/XMLSchema#"
},
@melvincarvalho
melvincarvalho / Introduction.md
Last active June 12, 2025 17:58
Introduction.md

2 Introduction

The Linked Web Storage (LWS) Protocol defines the minimum set of interoperable, HTTP-based interactions that let any conforming application read, write, and manage data that lives outside the application’s own infrastructure. Its purpose is to restore an essential architectural principle of the Web: users control where their data is stored while applications come and go—without breaking links, permissions, or provenance.

Today most Web applications entangle storage, identity, access control, and business logic behind a single origin. Migrating to a new provider or adopting a new application therefore often means abandoning existing data. LWS breaks that coupling. By standardising a small, resource-oriented contract it enables

  • portable personal and enterprise data vaults that can move between providers, clouds, or on-premise deployments,
  • application innovation decoupled from storage choices,
  • consistent security semantics across heterogeneous back-ends, and
@melvincarvalho
melvincarvalho / NIP-XX-Playlists.md
Created May 30, 2025 12:04
NIP-XX-Playlists.md

NIP-XX — Sharing .m3u Playlists via Event Content

Author: Melvin Carvalho Status: Draft Type: Standard Created: 2025-05-30 License: Public Domain