npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

ethix

v0.0.2

Published

A decentralized licensing platform

Downloads

1

Readme

Ethix Core Architecture

Decentralized CDN + License Verification by incentivized cooperation and self healing network behaviors.

The ContentRegistry is a contract

A content registry holds ownership data and content metadata.

  • Users can claim ownership of content.
  • Owners can license content to be sold for a price.

LicensedContent is a contract

Generated by the ContentRegistry when an owner (or valid re-licenser (future)) associates a price with content and specifies terms of the license.

  • Terms might include:
    • Purchase expiration date
    • Number of NetworkRequests
    • Usage of license expiration date
  • Users can purchase licenses from a LicensedContent.

Each License is a contract

Generated by a LicensedContent when a purchase is made.

  • As Licenses are created, the address is logged along with the content id encrypted by the licencee's private key and the users wallet address.
  • The caller must have registered a public key with the system (if not available already)

A License can vend NetworkRequests (Better on a lightning network)

NetworkRequests are contracts to facilitate a single data transfer request.

  • Creating a NetworkRequest sets aside a portion of license fee as reward (or, part of the request cost)
  • The request costs a fee which will be refunded once the user reports the data was received (or failed).
  • Nodes call to claim the reward, first come first serve (up to 10/20/100, etc distributors).
    • As discussed below, multiple servicers might increase reliability but cause problems with effort validation.
  • If node will get reward, they can independently act to send data.
  • User reports back with who did what to reclaim extra NetworkRequest refund.
  • Nodes are now eligible to collect their fee for work done.

Users create NetworkRequests

  • A user has an address for the license contract, and the user can recover licenses by scraping logs.
  • A user generates a NetworkRequest via the License and passes in a routing address known to the CDN.
    • This should not be an ip, we don't need to broadcast location data, and we want nodes to be forced to use the network infrastructure for communication, which allows checks to detect bad actors.
    • The network can resolve the address via n hops and limited knowledge, and does not require opening a direct connection to that address.
  • Generating a request logs the NetworkRequest address, License address, network destination.

A p2p CDN distributes content

  • Nodes pay an initial fee to participate.
  • Nodes are removed if they behave badly, sacrifice the participation fee, and get blacklisted.
  • Nodes get rewarded for being well behaved and doing work.
    • The NetworkRequest is how a node can claim the reward for work.
    • The funds for the rewards are made available by the license.

The network sends data

  • A node reads the log of NetworkRequests and decides to act on a given request.
  • The node attempts to claim some reward (response time after request generation is faster on lightning).
  • With a successful escrow confirmation, the node sends requested data.
  • User receives data and finalizes the request.
    • The original sender node info is sent encrypted by the destination's public key.
    • This guarantess the receiver can properly validate the node during the request finalization.

The user confirms the result (or becomes a bad actor):

  • Invalidates the token for further usage.
  • Transfers collatoral payment back to user.
  • Moves reward payouts to claimable location.
  • Logs state change so distributor nodes can claim reward.

Self-healing goals and behaviors

  • Make it hard if not impossible for malicious nodes and clients to exist.
  • Any clients not finalizing requests might be blacklisted by other network nodes and ignored for data transfer.
  • Any distributors sending data through the network without being registered can be ignored.
    • They probably won't be able to handshake and join valid nodes.
    • Because destinations are network-relative, not beng a valid network node will hinder ability to route traffic.

Problematic features

  • Any distributors avoiding the license checking calls can be discovered and blacklisted.
  • Clients can verify logs after finalizing access. Only nodes that successfully called the NetworkRequest (and thus validated a license with permission to send data) behaved well, and this fact should be rebroadcast through the network on violation.
  • Of course, every validation step to solve a bad pattern exposes another point of failure for a malicious client. Imagine that a nasty client broadcasts false failures of other nodes. Since the client is the only able one to validate where data came from against where it should have come from, this operation needs to take place on chain during the finalize phase. This might involve a lot of extra state data since small file chunks delivered by multiple sources (scratch that feature?)... Can we rely on first come first serve contract winning node to fulfill data promise reliably? Can we implement time-based retry with different provider without spamming traffic?