anselmobattisti

Capture and send video 

gst-launch-1.0  v4l2src device=/dev/video0 \
    ! decodebin \
    ! x264enc \
    ! rtph264pay \
    ! udpsink port=5000

Show the video
gst-launch-1.0 \

esneider

Non-custodial lightning escrow for HodlHodl

phase 1: bitcoin funding

1. seller generates secret A
2. seller asks hodlhodl to generate a hold invoice with payment hash = hash(A), notice that hodlhodl doesn’t have the preimage A
3. seller sends a lightning payment to settle the invoice
4. once hodlhodl receives the payment, it remains on hold since it doesn’t have the preimage A to settle it
5. hodlhodl lets the seller know it received the payment, so that it can proceed

phase 2: fiat payment

revskill10

CREATE TABLE accounts(
	id serial PRIMARY KEY,
	name VARCHAR(256) NOT NULL,
	parent_id INTEGER REFERENCES section,
    	parent_path LTREE
);

CREATE INDEX account_parent_path_idx ON accounts USING GIST (parent_path);
CREATE INDEX account_parent_id_idx ON accounts (parent_id);

t-bast

Phoenix in a splicing future (a.k.a death to all swaps)

Phoenix implements trusted swaps for users' convenience (to allow easy onboarding and offboarding). But it's not a satisfying solution for the following reasons:

• It uses two on-chain transactions for swap-in where one should be sufficient (one transaction from the user to Acinq followed by a channel open)
• Swap-out feerates are unpredictable (because we may fund the swap-out with unconfirmed previous outputs) which is frustrating for users
• It forces Acinq to use its own utxos, which doesn't scale well and is an operational burden
• If Acinq doesn't have any utxos available and the mempool is completely full, swaps are stuck which is also frustrating for users

mrbluecoat

• Amnezia VPN (OpenVPN & WireGuard protocols) - Windows, MacOS, iOS, Android, Linux (no ARM support)
• boringproxy (in-house developed "NameDrop" protocol) - Windows, MacOS, Linux, FreeBSD, OpenBSD
• boringtun (WireGuard protocol) - MacOS, Linux (mobile clients not open source)
• Brook (in-house developed "Brook" protocol as well as WebSocket Secure, SOCKS5, and QUIC protocols) - Windows, MacOS, Linux, OpenWrt (mobile clients not open source)
• Chisel (SSH protocol) - Windows, MacOS, Linux
• cjdns (in-house developed "CryptoAuth" protocol) - Windows, MacOS, Linux, FreeBSD, NetBSD
• Cloak (OpenVPN & Shadowsocks protocols) - Windows, MacOS

kassane

#include "tb_client.hpp"

int main() {
  tb::Client client("localhost", 8080);

  tb::Account account({0, 0, {0}, 1, 1, TB_ACCOUNT_LINKED, 0, 0, 0, 0, 0});
  tb::create_account_result result = client.create_account(account);
  if (result != TB_CREATE_ACCOUNT_OK) {
    // Handle error
  }

j4w8n

Implement user API keys with Supabase

Rationale

JWTs are at the heart of Supabase authorization, but sometimes we wanna build an app that also gives users access via API keys; or perhaps only exclusively via API keys. As you may know, using JWTs as API keys makes them difficult to revoke and therefore a security issue.

We also want to ensure this doesn't significantly add to RLS polices, if at all.

Finally, we'd love to have this handled by Supabase and do as little as possible in our framework. This simplifies our code and reduces third-party libraries.

Solution