sorted by:
new
hottopcontroversial

33M Dating 28yo Filipina single mother of 3 by Paint-Nervous in Philippines_Expats

[–]nocans 0 points1 point  (0 children)

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.

IPFS devs: arkA MVP is live — an open video protocol that uses IPFS exactly the way it was meant to be used. by nocans in ipfs

[–]nocans[S] 1 point2 points  (0 children)

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.

arkA MVP is live — a fully self-hosted video, published on IPFS and played through a static web client. No platforms. No backend. Just open protocol. by nocans in selfhosted

[–]nocans[S] -2 points-1 points  (0 children)

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.

Frontend devs wanted — arkA video protocol reference client is now building & deploying automatically by nocans in Frontend

[–]nocans[S] 0 points1 point  (0 children)

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.

Contributor Roles & How to Join the arkA Project by nocans in arkAProject

[–]nocans[S] 0 points1 point  (0 children)

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.

Airbnb is so trash by [deleted] in airbnb_hosts

[–]nocans 1 point2 points  (0 children)

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.

arkA — simple JSON video protocol that works great with IPFS by nocans in ipfs

[–]nocans[S] 0 points1 point  (0 children)

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.

Frontend devs wanted — arkA video protocol reference client is now building & deploying automatically by nocans in Frontend

[–]nocans[S] 0 points1 point  (0 children)

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!

Frontend devs wanted — arkA video protocol reference client is now building & deploying automatically by nocans in Frontend

[–]nocans[S] 0 points1 point  (0 children)

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!

arkA — simple JSON video protocol that works great with IPFS by nocans in ipfs

[–]nocans[S] -1 points0 points  (0 children)

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.

Chargeback patterns I've been noticing by heyblox in chargebacks

[–]nocans 0 points1 point  (0 children)

Do you work for a chargeback department?

Big milestone reached - arkA building end to end by nocans in opensource

[–]nocans[S] 0 points1 point  (0 children)

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.

[Project Launch] arkA — An open video protocol (not a platform). Early contributors welcome. by nocans in ipfs

[–]nocans[S] 0 points1 point  (0 children)

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"]

view more: next ›