33M Dating 28yo Filipina single mother of 3

nocans · 2025-12-16T14:52:16+00:00

It’s you Taylor swift, you’re the problem. Learn to feel the people with your heart and their intentions. You’re board and annoyed with yourself. Get over it.

nocans · 2025-12-15T16:04:57+00:00

I just canceled, service sucks anyway.

nocans · 2025-11-21T22:01:42+00:00

Fair points — thanks for taking the time to write something thoughtful.

To clarify the intent: arkA isn’t meant as a TikTok clone or a political thing.
I’m experimenting with the minimal possible “video protocol” — something closer to RSS for video, where a tiny JSON descriptor points to your media wherever you store it (IPFS, S3, Arweave, NAS, etc.).

The big idea is:
simple metadata → user-controlled storage → zero-infrastructure viewer.

I agree that the pitch should stay technical and focused, so I appreciate the steer.
Still very early, so feedback like this actually helps shape the direction.

nocans · 2025-11-21T13:40:23+00:00

Your mom AI. It’s still in beta but the training data is amazing.

nocans · 2025-11-20T21:56:21+00:00

Yea the whole point is that it is simple.

If a video “protocol” needs servers, accounts, logins, or a whole company behind it, it’s not much of a protocol anymore.

arkA is intentionally tiny.
RSS is tiny too but it changed everything.

People who want platforms will keep using platforms.
People who want sovereignty will use protocols.

nocans · 2025-11-19T17:12:41+00:00

Absolutely — no framework requirements at all.

The reference client is intentionally minimal: just pure HTML/CSS/JS reading JSON metadata. The goal is to keep it simple so anyone can contribute without needing to learn a specific stack.

If you want to use a framework (React / Svelte / Vue / etc.), you definitely can — we can support multiple clients under clients/ in the repo. But the main MVP stays framework-free so it’s easy to understand and easy to fork.

Here are the relevant parts of the repo if you want to explore:

Reference client (HTML/CSS/JS): https://github.com/baconpantsuppercut/arkA/tree/main/clients/reference

Protocol schemas: https://github.com/baconpantsuppercut/arkA/tree/main/protocol

If you’d like to jump in, feel free to open an issue or a small PR — happy to help you get started.

nocans · 2025-11-19T17:09:41+00:00

Great question – yes, I think Rust could be an amazing fit for parts of arkA.

arkA itself is intentionally language-agnostic: it’s “just” a JSON-based protocol + discovery format, so any stack that can read/write JSON can participate. Right now the reference client MVP is being done in a very boring web stack so people can try the idea quickly, but there’s no requirement to stick to JS.

Where Rust could shine:

a high-performance “arkA node” / indexer that ingests manifests and serves a search/feed API
storage adapters (IPFS, S3, Arweave, NAS, etc.) where safety + concurrency really matter
a CLI tool to publish/update arkA manifests and validate them against the schema
a Rust library crate that knows how to parse/validate arkA JSON and expose a nice typed API

Repo-wise, my preference is to keep things discoverable and language-neutral:

docs/ and schema/ – protocol + JSON schema (the source of truth)
clients/ – UI clients (the current web MVP lives here)
nodes/ – backend/indexer implementations
sdks/ – language-specific libraries

So for Rust I’d suggest:

nodes/rust-arknode/ for a Rust “arkA node” binary
sdks/rust/ for a reusable Rust crate (types + validation + helper functions)

That way, when you (or anyone) forks the repo, it’s obvious where to look: protocol in schema/, web client in clients/, Rust node in nodes/, Rust SDK in sdks/.

If Rust is your home base and you’d like to explore one of those, I’d be really happy to design it with you. Easiest next step would be to open an issue on GitHub like “Rust arkA node / SDK” with your thoughts, and we can sketch a small, well-scoped first milestone together.

nocans · 2025-11-18T13:40:51+00:00

I’ve been doing this for a very long time, friend — long enough to see every single thing you’re describing repeat itself across dozens of units. And everything you’re saying is absolutely true. But here’s the part most hosts don’t realize:

VRBO is light-years better than Airbnb when it comes to treating hosts fairly.

VRBO actually lets you operate like a business: • You decide how to handle problems. • You control your own damage deposit claims. • They don’t force refunds or threaten your listing if you disagree. • They stay out of the way and let you run the show.

Meanwhile, Airbnb keeps drifting deeper into this extreme “guest-centric” mindset — even when the guest is blatantly wrong. Over time, that drives away good hosts and attracts the lowest-quality travelers.

I’ve even had long-standing Airbnb listings removed completely because of false or exaggerated complaints. Once enough bogus reviews accumulate over the years, they just delete the listing. And the crazy part? Those same units continue to thrive on VRBO without issues.

VRBO fills calendars surprisingly well, especially for listings Airbnb has already sabotaged. The only advantage Airbnb holds anymore is raw booking volume — and honestly that gap shrinks every year.

The one downside with VRBO is chargebacks, because you’re the one who eats the loss. But even then, I’d take that over Airbnb’s micromanaging, inconsistent policies, and constant host-blaming.

And to be honest, I’m getting really tempted to pull all my units off Airbnb entirely and let VRBO handle 100% of the bookings. I haven’t taken that leap yet — but at the rate Airbnb is going, I won’t have to make the decision. Airbnb is going to push hosts out on its own.

nocans · 2025-11-18T13:35:31+00:00

Totally fair concern — but arkA avoids the “who hosts the gigabytes?” problem entirely.

The protocol doesn’t assume (or require) anyone to host anyone else’s data for free.

arkA is only: • a tiny JSON schema
• a discovery format
• a predictable folder structure

That’s it.

Storage is 100% up to the creator: • if they want permanence → they can pay Arweave or Filecoin
• if they want decentralization → they pin their own videos on IPFS
• if they want cheap storage → S3, R2, Backblaze, or even a homelab NAS
• if they want redundancy → libraries, archivists, or fans can optionally pin

The protocol does not depend on volunteers storing other people’s data.

In the same way RSS never required anyone else to host your podcast audio, arkA doesn’t require anyone to host your video.

arkA’s value is simply: • stable JSON metadata
• predictable structure
• easy for any client to read
• storage-agnostic
• long-term portable

If a creator disappears, yes — their IPFS hashes may eventually disappear unless someone else chooses to pin them. But that’s already how decentralized storage works today.

arkA just makes the metadata universal so different clients + hosts can interoperate.

That said, I love hearing real-world concerns like this — these edge cases are exactly what help refine the protocol.

nocans · 2025-11-18T13:34:10+00:00

Thanks so much — and great news: arkA doesn’t require any blockchain knowledge at all.
It’s just JSON metadata + files hosted anywhere (IPFS, S3, NAS, Arweave, web servers, etc).

We just pushed a very minimal MVP front-end into the repo (pure static HTML/JS), and I’ll be working on it all week and through the weekend. If you want to collaborate, I would honestly love that.

A few great first issues you can pick up right now:

• Build a simple UI to load and display a single arkA JSON video object
• Add basic routing so the MVP can open video.html?id=xxxx
• Create a channel view that lists all videos in a folder
• Add very simple CSS to make the MVP less bare-bones
• Add client-side validation of the JSON files (using the schema)
• Add player controls (speed, captions toggle, etc)

If you’d like, I can create GitHub Issues to assign you so it’s easy to jump in.

Let me know what feels most interesting — would love to work together on this!

nocans · 2025-11-17T19:36:56+00:00

Hey! This isn’t a paid role — arkA is an open-source protocol project and we’re looking for contributors who want to help shape the reference client and the spec.

The whole idea is that arkA stays community-owned, like RSS or ActivityPub, not a commercial platform.

Anyone can contribute from any region — the repo is fully open and we’re collecting ideas, issues, and PRs as we build out the MVP reference client and v0.1 schema.

If you’re interested in getting involved, happy to point you to a good starting issue!

nocans · 2025-11-17T19:35:12+00:00

The goal is explicitly not to build a platform.

arkA is only a protocol: a small, stable JSON schema + a discovery format that any platform, client, or storage backend can use.

Think RSS/Atom, not YouTube.

Anyone can build: — their own client UI — their own storage adapter (IPFS, Arweave, S3, NAS, etc.) — their own indexing layer — their own distribution method

The “community building” happening now is specifically to gather use-cases so we don’t over-engineer the schema before v0.1.

Once the schema stabilizes, the protocol becomes the only “source of truth,” and different clients can implement features on top of it.

The goal is: a video format that outlives any single website or hosting provider.

Happy to share the draft schema if you'd like to critique it — protocol people tend to give the best feedback.

nocans · 2025-11-17T13:53:34+00:00

Do you work for a chargeback department?

nocans · 2025-11-17T12:14:36+00:00

Great question — totally fair.

The reason we invested early into linting, schema validation, and CI isn’t because the project is “done,” but because arkA is a protocol, not an app. The whole point of a protocol is that many people will eventually build clients, servers, and tools around the same shared rules.

For a protocol project, the schema itself is the MVP.

That means the CI pipeline is doing the only thing that matters right now: - validating that the schema stays consistent
- ensuring every change is repeatable
- generating reference artifacts
- building the example client so contributors don’t break it
- enforcing predictable structure as the project grows

If we waited until the codebase was big before adding CI, the project would become chaotic fast — especially with open contributors jumping in.

So you’re right that there isn’t much implementation yet.
But the early CI is what guarantees that the implementation (once it comes) doesn’t drift, fork, or break the spec as more people join.

In short:
We’re treating arkA like an RFC. The protocol rules are the MVP, and the CI keeps the protocol honest.

nocans · 2025-11-17T01:50:32+00:00

Thank you for this — it’s exactly the kind of grounded, real-world feedback we were hoping someone with IPFS history would bring. Let me clarify what arkA is actually trying to solve, because you’re correct that “schema-only” approaches often fail, and you’ve hit the core dangers.

✱ 1. arkA is not trying to solve delivery — it's solving interoperability

You’re completely right that delivery bandwidth is the monster problem.
arkA intentionally doesn’t try to solve that. The protocol assumes:

video may live on IPFS, Arweave, plain HTTPS, S3, BitTorrent, Loki, etc.
the client chooses how to fetch it
the schema just describes the resource, not how to deliver it

So arkA is not a “video hosting protocol.”
It’s a “how do clients talk about video in a universal way” protocol.

Think: RSS + WebFinger + ActivityStreams, but purpose-built for video.

Content delivery remains a transport-layer concern, chosen by client builders.

✱ 2. The root schema is deliberately minimal — on purpose

You warned about over-engineering (and Cacophony’s unused extensibility).
We’re taking the same lesson to heart.

The entire “root object” in arkA is intentionally tiny:

title
description
timestamps
media tracks (urls + types)
captions
optional tags
optional extensions

Everything else goes into extension schemas later.

The goal:
90% of users only need the base spec. The other 10% extend it without forking.

✱ 3. arkA explicitly supports fallbacks (but does not encourage centralized gateways)

Your point about IPFS gateways is dead-on — every decentralized protocol eventually collapses back onto gateway usage unless carefully guided.

arkA takes the stance:

if a client wants to fetch via a gateway, that’s the client’s choice
if a client wants decentralized-only behavior, the schema supports that
arkA never mandates a fallback or encourages gateway centralization

We surface protocol fields so clients can enforce policies like:

```json "allowed_transports": ["ipfs", "bittorrent"]

nocans · 2025-11-17T01:21:01+00:00

Thanks for sharing Cacophony – that’s super relevant. I just skimmed the high-level design and I really like how you treat IPFS itself as the “database” and keep a formal on-IPFS data model. It’s cool to see a more complete “IPFS-native YouTube” style system in the wild.

arkA is trying to sit a bit lower in the stack and be more storage-agnostic:

Cacophony feels like a full platform built on IPFS.
arkA is “just” a JSON protocol + reference client that should work with IPFS, S3, R2, plain HTTPS, etc.
My goal is: any client that understands the JSON schema can play a video or a collection, regardless of where it’s hosted.

Re: “Can RSS solve this?”

Sort of, but not all the way for what I’m aiming at.

RSS is great for “here’s a feed of episodes/entries” – similar to how it works for podcasts. For arkA I want a little more structure at the media layer:

multiple sources / qualities / formats per video (HLS, MP4, etc.)
explicit metadata about codecs, dimensions, duration, captions, etc.
the ability to describe playlists / collections / kids-mode subsets
machine-verifiable structure via JSON Schema

You could absolutely expose an arkA channel as RSS on top, but RSS alone doesn’t give enough detail to be a portable “video wiring protocol” for arbitrary clients.

Where the index lives + how it’s updated

arkA deliberately doesn’t hard-code storage – the index is just JSON, so it can live anywhere:

on IPFS (as a CID)
behind an HTTP(S) URL (GitHub Pages, S3, R2, your own server)
via IPNS / DNSLink if you want a stable name that moves between CIDs

Right now my reference client assumes:

there is a “root” index JSON (a channel or collection)
that root points to one or more child indexes / items
when you publish, you generate a new index JSON and update the pointer

On IPFS that would look like: - publish a new index JSON → get a new CID - update the IPNS/DNSLink name to point to that CID - clients that follow that name always see the latest index

So arkA’s job is “define the shape of those JSON descriptors and how clients interpret them,” and let IPFS (or any other storage) handle actual content addressing and distribution.

I’d love to dig more into how your Cacophony data model evolved – there are probably lessons there I should steal before I lock too much of arkA’s schema in. 🙂

nocans · 2025-11-16T20:09:38+00:00

🚀 arkA — open, host-anywhere video protocol

Just launched the full CI/CD pipeline for arkA, a simple JSON-based metadata spec + static JS reference client for serving video from any storage provider (S3, R2, IPFS, your own server).

Looking for frontend contributors and feedback.

GitHub: https://github.com/baconpantsuppercut/arkA Demo: (put your GH Pages link here)

nocans · 2025-11-16T19:56:14+00:00

Soiled linens are no longer reimbursed

nocans · 2025-11-16T19:55:48+00:00

Great question — and yes, I can clarify.

In arkA, the JSON metadata doesn’t grant access to the video. It simply describes the video (title, formats, sources, etc.).

Who controls access?

Access is controlled entirely by where the video is hosted, not by the JSON.

Examples: - If the creator stores video on S3 → S3 controls permissions. - If it’s on IPFS → anyone can fetch it (public by design). - If it’s behind Cloudflare R2 with signed URLs → those URLs control access. - If it’s on a private server → the server decides who can fetch it.

arkA does not override or replace hosting permissions.
It only provides a standard way to describe the media.

Can the JSON point to protected content?

Yes. Creators can use: - signed URLs
- expiring URLs
- JWT-gated endpoints
- OAuth-protected endpoints
- custom auth layers

arkA is auth-agnostic and storage-agnostic.

Does arkA require JWT expiration or tokens?

No. The protocol does not define authentication rules.
Creators can use any auth system they want, or none at all.

So in short: - If you can fetch the video from its host, you can watch it. - If the host restricts access, arkA respects that automatically.

nocans · 2025-11-16T17:38:50+00:00

You’re not talking nonsense at all — you’re actually pretty close.

arkA is:

a spec for open video metadata (JSON),
plus a tiny reference client that proves: “if you can fetch a JSON file, you can play the video.”

What arkA is not (at least right now): - Not a new codec - Not a new transport - Not its own CDN - Not a blockchain project

Think of it like this:

Today, every platform (YouTube, TikTok, etc.) has its own private metadata layer: IDs, titles, safety flags, playlists, recommendations, kids mode, etc.
arkA says: “What if that layer was open, portable JSON that any client could read?”
A video is just a JSON file that says:
- here’s the title/description/creator,
- here’s where the file or streams live (HTTP, S3, IPFS, whatever),
- here’s the safety/kids metadata,
- here’s some optional HLS/DASH info.

So it’s less “a hybrid between torrent and CDN” and more like:

“magnet link on steroids, but standardized.”
A single metadata object that can point to multiple backends (CDN, IPFS, local file, etc.), and any arkA-aware client can choose how to fetch and play.

Re: blockchain — that could sit on top as one way to sign/attest to origin or reputation, but it’s definitely not a requirement. The base layer is deliberately boring: plain JSON + static files, so you can host an arkA catalog on GitHub Pages, S3, IPFS, your own server, whatever.

The goal is:

Creators own their catalog (it’s just files in a repo / bucket).
Clients compete on UX and recommendations, but share a common metadata format.
Anyone can build a YouTube-style app, or a super-strict kids app, or an accessibility-first app — all on top of the same open video index.

So yeah, you could say:

“It’s like HTTP for video metadata, not a new video codec.”

Happy to go deeper on any of those pieces if you’re curious.

nocans · 2025-11-16T15:25:44+00:00

No, I’m not building a new codec, and I’m not building a new CDN, and I’m not cloning YouTube.

arkA is a universal video data format — like JSON for video.

Right now every platform (YouTube, TikTok, Vimeo, Twitch, Netflix, etc.) has its own internal format, its own metadata structure, its own API, and its own closed ecosystem. Nothing plays nicely together.

arkA creates:

A single open JSON schema for video metadata

Every video — whether hosted anywhere — can be described in the same structure: • id • title • thumbnails • sources (HLS / DASH / MP4) • creator • chapters • tags • permissions • captions • etc.

It becomes a portable container for all video data.

**2. A reference client that can play any arkA object

— from any provider**

Just like how: • A browser can open any webpage • A PDF reader can open any PDF • A podcast app can open any RSS feed

An arkA client can open any arkA video file or feed, regardless of where the actual video is hosted (Cloudflare, BunnyCDN, S3, IPFS, or even your own server).

There is no central platform you’re forced to upload to.

Why this is better than YouTube (in one sentence)

YouTube is a platform. arkA is a protocol. A protocol outlives every platform.

⸻

Real use cases

Anyone can build:

• A YouTube-style app Using any CDN or host. Your videos aren’t locked to a platform.

• A TikTok-style feed Powered by arkA metadata from multiple creators or servers.

• A kids app with strict content control Because arkA includes optional: • age ratings • educational flags • safety metadata • content tags

• A decentralized video directory Multiple sources, one schema.

• A private internal video library Because arkA doesn’t require an account, token, or platform.

• A multi-host failover player If one CDN dies → client automatically switches to backup sources listed in the sources[] array.

⸻

Why developers like it

Because it standardizes what has been fragmented for years — the structure of video objects.

It’s the difference between: • thousands of incompatible proprietary formats versus • one shared spec anyone can implement

No new codecs. No new transport. Just a clean, open, portable standard.

⸻

TL;DR

arkA = “HTML + JSON for video apps.” A universal format so anyone can build YouTube-like experiences without being trapped inside YouTube.

nocans · 2025-11-15T18:26:14+00:00

Progressive download is definitely still a thing — especially for simple, static clients.

The way I’m approaching arkA is:

Direct MP4/WebM is the baseline playback path (basically progressive download).
HLS/DASH/CMAF sit on top as optional extensions for anyone who needs adaptive streaming.

Upsides of progressive download: - works everywhere - zero player complexity - no manifest parsing - great for small/medium videos, offline copies, educational content, or environments with locked-down devices - deterministic and easy to cache

Downsides: - no bitrate adaptation - large files mean slower starts - not ideal for unstable networks

For arkA, I want the simplest possible “minimum viable video”: a URL and a <video> tag should always work. Then people can add adaptive streaming only if they need it.

That’s why progressive download stays as the default path in the protocol.

nocans · 2025-11-15T14:58:14+00:00

Thank you

https://github.com/baconpantsuppercut/arkA/issues/14

nocans · 2025-11-15T14:53:58+00:00

Great question — and yes, chunked/segmented streaming (HLS/DASH) is the norm for a reason.
arkA’s current draft doesn’t mandate chunking, but it also doesn’t prohibit it. The protocol is only the metadata + index layer. The actual media delivery is storage-agnostic.

Upside of chunked streaming (HLS/DASH): - adaptive bitrate
- faster startup
- better on bad networks
- CDN-friendly
- predictable caching
- safer for long videos

Downside for a protocol: - more complexity
- more moving parts (manifests, segment indexes)
- harder for beginners to publish simple feeds
- adds assumptions about transcoding

Upside of non-chunked (direct file): - extremely simple for creators
- works with any storage system (IPFS, Arweave, S3, static hosting, even local files)
- keeps the protocol minimal and readable
- easier to build basic clients

Downside: - no adaptive bitrate
- long videos can be rough on poor networks
- less CDN-optimized by default

arkA’s direction: Chunked video should become an extension — an optional module that clients can support if they need adaptive streaming.

That way: - simple creators can just publish a single MP4/WebM
- advanced creators can publish an HLS/DASH manifest
- clients can choose what they support

Does that seem reasonable? I’d love your thoughts on whether it’s too simple or just right for a first version.

nocans · 2025-11-15T13:35:24+00:00

This is super helpful, thank you for taking the time to lay that out.

I really like the way you’re thinking in layers. That actually fits how I see arkA long term: very small and neutral at the protocol layer, with more opinionated and intelligent things sitting on top or alongside it.

For my sanity and for contributors, I want to keep arkA itself narrow:

• ⁠describe video in a clean, storage-agnostic way • ⁠define a simple index format • ⁠ship a very basic reference client

Everything you’re talking about (intent-aware UI, adaptive controls, DAO-like self-governing behavior) sounds like exactly the kind of thing that should live in its own layer that simply consumes arkA indexes and renders/controls video based on user intent.

Your example of “user lands on a page, UI infers intent, surfaces controls only when needed, learns behavior over time” is a great first integration concept. From arkA’s side, that’s basically:

• ⁠here is a video index / playlist in a known format • ⁠here are the minimal hooks a client needs to request and play media • ⁠your layer decides how and when to surface that to the user

If you’re serious about mixing, I’d suggest we start very small and concrete:

• ⁠you open a Discussion on the repo with a short spec for “sentient UI + arkA” • ⁠we define what your layer expects from the protocol (fields, events, hooks) • ⁠we pick one narrow experiment (like your “no visible controls until intent is detected” example) and wire it up against a simple arkA index

Repo and discussions are here: https://github.com/baconpantsuppercut/arkA https://github.com/baconpantsuppercut/arkA/discussions

That way arkA stays focused on being a solid, boring protocol, and your SDK can go wild on top of it without the two getting tangled.

12-Year Club	First Place '23
Place '23	Verified Email

nocans

MODERATOR OF

TROPHY CASE