mankins

You can keep reading as much as you want, there's a button at the end of the email that sends the next installment.

There's also an option to send multiple times a day.

Since 2003 I've been on a mission to help people "read instead".

From my experience as a bookseller I know that most people want to read more, but the full context switch to "reading" is increasingly difficult for many. I could be biased, but I've always found email to be underappreciated as an app platform.

With Driplit I wanted to use email as a way to fit books naturally into my day. Driplit allows you to read books over email, one ~500-word "drip" at a time. We have about 1500 public domain books at the moment. I recently allowed uploading private EPUBs too.

I'd love to hear what you think.

ps - https://alivreouvert.net/2015/03/19/une-bibliotheque-peut-el...

The "read instead" photo is my old bookshop Lorem Ipsum Books. The blog is not mine.

Would love to get feedback on this version. I've been thinking about this for awhile and recently revived something I first posted on HN back in 2009: https://news.ycombinator.com/item?id=586798

Eventually I realized that asking for payments, even as micropayments, doesn't work as the mental transaction cost is just too much. Instead I got inspiration from Ted Nelson's concept of "transcopyright" where the creator of the content is interlinked with the content itself. This too had its complexities so I simplified the linkage to be indirect by picking up existing ids that were near the content and using those as the basis for a retroactive value system I called kudos.

Today's implementation is a browser extension that looks for existing ids: things like GitHub/HN/Reddit/Youtube/Twitch/Bluesky/X/email, etc... and uses that to define your "corner of the web". Essentially these are the people that make the web pages you depend on, a kind of personal attribution graph.

You can put in a url on the home page and get a rough idea how this might work.

After a month you'll have a distribution which we use to send points to, and those points can optionally get converted back. It's kind of like shareholders buying shares in a corporation, and then later getting a dividend based on their ownership.

To encourage people to pay I built a "universal tier" system where you can cause some of your work to be paywalled behind having a tier access. Unlike something like Patreon you would be supporting the whole web rather than just one person. Tiers can gate access via a web component we have on the apps section, or via a Discord bot.

The best way to see it in action is actually with the browser extension, however you can also CC: a special email address to create kudos. That's probably too much so I'll leave it there, but happy to answer questions.

In a flash of nostalgia from my early web programming I remembered the names "Rob McCool" and "UnCGI". Much to my surprise what looks like the original Uncgi source code and website is still available. This is what open source looked like before GitHub.

I recently did something similar but as a Mac app.

It sounds like a similar stack, but distributed as an app. FFmpeg (LGPL compilation).

I haven't tried Pixi.js, looks interesting. I guess it was good for this.

Have you looked at remotion? I found them good for somethings, but ended up using Safari for rendering (instead of remotion's chrome-based rendering) because app packaging was easier that way.

https://www.loremlabs.com/cliproom if you're interested in comparing

Nope, not an outline prompt. Just my early morning jumble. (We still might be screwed, but I like to think not!)

That sounds closer to achieving a good outcome. Of course I think anything that includes the set of all users as columns will be game-able. You need to either choose the set yourself from "trusted peers" or "foaf" degrees, or maybe better use retroactive signals rather than purely like-driven approaches.

The spoilage by money is half right, but I think the more interesting part is where the money ends up and how that influences the system.

I'm increasingly convinced the issue isn't feedback itself, but centralized, global, aggregated feedback that becomes game-able without stronger identity signals.

Right now the incentives are tied (correctly or not) to these global metrics, so you get a market for faking them, with money flowing to whoever is best at juicing that signal.

If instead the signal was based on actual usage and attributions by actual developers, the incentives shift. With localized insight (think "Yeah, I like Golang") it becomes both harder to fake and harder to get at the metric rollup.

Useful reputation on the web is actually much more localized and personal. I gladly receive updates on and would support the repos I've starred. If I could chose where to put my dollars (not an investors), it would likely include the list of repos I've personally curated.

This suggests a different direction: instead of asking "how many stars does this have?", ask "who is actually depending on this, and in what context?" or better retroactively compare your top-n repos to mine and we'll get a metric seen through our lenses. If you want to include everyone in that aggregation you'll end up where we are now, but if in stead you chose the list, well, the stars could align as a good metric once more.

The interesting part is that the web already contains most of that information, we just don't treat identity as a part of the signal (yet? universally?).

Doesn't the web already have implicit identities? And maybe that's enough for some use cases. I guess that's my take away.

I mean isn't this just a side effect of DIDs coming out a time when a lot of activity happened with blockchains? They came from w3c, a web org.

I guess my experience is similar to what you're saying though: we didn't really need that crypto layer to immediately gain value. But the way it compressed ids into a single namespace, that was useful.

SaaS pricing is tough. Free trials work, but startups often need a middle ground between free and enterprise without requiring a credit card. That's why we built betapass—users pay for access, and funds are distributed based on usage.

They are labeled "fake" and there's a pretty obvious call to action to replace them with human testimonials when we have them. It certainly seems better to call them out as not real than have them try to pass as real. What they're trying to convey though is valid and hopefully helpful to the reader. It's a good question though and I'd certainly be willing to learn from it if there's an obvious violation.

These are good questions. I'm not sure. As it was a quick project I didn't start with user research, although remember the people that were interested in it last time I had a similar product were lawyers and their clients who had copyright claims. The ability to use the core technology here–a hash–is on every computer, so you could certainly do this yourself. We just make it easier in terms of interface, using the blockchain as a database of sorts.

Some posts above about alternative ways to do this. I'm not aware of any that integrate with the Finder.

Right the nonce–the "dibs code"–is there so that you can't just copy a known sha256 and claim it as your own. You have to at minimum have the file, and to prove you have it one way is to come up with some random data and hash that random data + the actual data. Then others can do the same to show that it indeed matches. Once a nonce is used it can't be re-used for the same reasons.

The AI use case is an interesting one.

What's changed? The interface and primitives available for building applications. Rather than having to create a blockchain, we can _use_ a blockchain to do the timestamping.

Our insight is that this is still too hard to have quick access to use the blockchain meaningfully. So this service is a wrapper around those blockchain/cryptography primitives making it easy to create and lookup. It's the indexing part that can make the difference between a useful app in theory and in practice. In theory anyone could read the blockchain and create their own index from certain data on it...in practice that's more work than most will do... hence this kind of service.

Will this help in legally binding claims?

Not her words, but it can help prove that something existed at a point in time. It doesn't necessarily mean that you were the first but it does mean that you had it at that point in time. As I understand it, in copyright practice you take a work you've written, put it in an envelope and send it to yourself. The postmark shows that it existed at that point in time. (You don't open the envelope until some sort of legal procedure makes that required.)

Can anyone take a file and check on the site to see who has logged it?

Exactly, it's a light-weight way to record that you had a file without storing the whole file.

I should mention the word "Dibs" is a bit slang for meaning "i had that first" https://www.reddit.com/r/NoStupidQuestions/comments/nz92om/w...

Happy to show everyone Dibs ... a new data fingerprinting/notary service that writes to a public blockchain so you can prove you had a file at a point in time.

The recent chapter of this story starts on a train to Fosdem, the open source convention in Brussels at the start of February. I wanted something not related to my main work and so I started hacking together a Finder extension for the Mac to fingerprint data with a right-click interface suggested by my lawyer a few years prior. By the return trip I had the sketch of something working.

But the back story–not quite chapter one but close enough–happened a very long time ago. Let's call it 1999. I had a service called digitalpostmark.com that was an email server that would "postmark" the messages coming through it, adding a fingerprint to the message. If someone wanted to verify the email was sent at that point in time they could verify with our database and further re-compute the fingerprint themselves to see if the message had been tampered.

While this was a fun product (read: neat tech, low demand) it would eventually pivot to become SMTP.com's first product (I bought the domain for this), a way to relay emails in an era when mail servers were transitioning from open to closed. It turned out that the postmark server had everything we needed to change our email servers from a open relay into a selective open relay for users that bought our service subscription.

I would go on to sell the company and not think too much about digital fingerprinting until the NFT era reminded me of the power of hash functions and my now lawyer would lament about the power of an os-interface to the hash function.

Dibs goes one step further, allowing for easily creating fingerprints of files from the desktop as well as a web interface. These fingerprints include a "dibs code" proof that allows multiple claims of possession, but there's only one first.

The ordering of claims would be important, so I decided to use a public blockchain to write the records for all to see. End users don't have to know anything about blockchains, we do all of this behind the scenes, but expose the records so others can verify the transactions. (The blockchain chosen is the XRPL, for those interested in crypto).

I almost wrote an API for Dibs, but decided that the blockchain itself is an API, and it'd be better to just allow others to use that. So if a developer wanted to create their own system on top of Dibs, they'd just need to send a transaction on the blockchain to our "ingress" wallet address. That will then get indexed and available on the Dibs website the same as if the transaction was created with our interface. (Bonus: the per-transaction cost for the developer can be lower than our web interface, and yet is high enough that we still make money from the transaction payment.)

I suspect that most people will want to use the standard web interface. For that we chose a credit-based pricing model: $10 for 20 credits. Each Dibs is one credit, simple enough.

In talking to some potential users I came across some other example use cases, for instance my daughter wants to prove that she was the original creator of her avatar. While this current implementation is quite general, I suspect that there's quite a bit of work to do figuring out what a market segment might need and building the interface for that segment.

Is this the core of our business? No, at least not at the moment. Although the last time I started hashing things it turned into a business listed on the public markets, so you never know. I'd love to hear what you think we should do with it to improve the product. Thanks!

This is a chrome extension that integrates with AI models to give summaries, right? Any plans for non-chrome? what's next/was hard?

I created a similar service to this called Monetized.Link https://www.monetized.link/ ...We describe it as if you put together a tiny url and a paywall. From what I've seen there's a fair amount of interest in easily converting a link into money. Like Gumroad we've tried to make it as easy as possible, but more to be done.

Our team's background is in content so we initially were imagining this as a paywall for one-off content. You could put these monetized links inside a newsletter or twitter stream for instance and get an easy to create payment stream from your exiting users.

Over the product's development we have found support with the web3 community doing token gating (get the premium content if you own an NFT for instance).

This is the world premiere screening, happening right now. It's exclusively for Coil/ web monetization members. Is this the way to pay for content in the future?

There's also the Web Monetized site Cinnamon: https://www.cinnamon.video/

I learned this hack from Mr. Rogers. :)

We built the Condé Nast paywalls (New Yorker/Wired/Vanity Fair) using the 402 status code. A 402 indicates to the browser that no acceptable payment method was negotiated and the content returned is not the full url requested.

We imagine clients sending an "Accept-Payment" header just as they send an "Accept" or "Accept-Language" header today. When the server is unable to satisfy their request, it returns a 402 indicating that no acceptable payment method was found.

It's true that browsers may not be currently sending these Accept-Payment headers; we auto-create the headers at the edge based on other headers (cookies). Conceptually this simplifies our stack and gives us a way that we might be able to have more of a "conversation" between web users and the site about how they want to monetize our content.

For instance a user may have ad-block enabled so why not tell the server that ("Accept-Payment: ads;q=0") and we'll serve the page based on this information.

I envision a future where the web browser may have multiple payment methods built into it (micro-payments, subscriptions, ads, etc.) and a "conversation" happens between the client and server to figure out what the "best" way forward is for both parties. We don't need new headers or methods for this, we simply need to re-use existing status codes and headers.

Condé Nast (Wired, The New Yorker, etc) | New York, NY, USA; Austin, TX, USA | Full-Time | Onsite, Remote | Full-Stack, Payments Engineer

Condé Nast is looking for an ambitious engineer to join and help us build the next generation of our digital products. You will work closely with our Subscriptions teams in their shared mission to develop healthy and sustainable ways to grow subscription revenue.

We make heavy use of NodeJS, React, GraphQL, and VCL. Many other positions open.

Apply: https://condenast.wd5.myworkdayjobs.com/en-US/CondeCareers/j...

Questions: matt_mankins@condenast.com put 'hacker news' in subject

I know your group used to work at {Newsweek, Daily Beast, Fast Company} (I've worked with both Mark and Andrew before)... I wonder if you could talk a bit about how the experience with these legacy CMSs influenced your design with TakeShape?

I'd also be curious to know which GraphQL server are you using on the backend? Apollo? Any challenges with getting that into production?

This is Condé's third full-site paywall, following behind our implementations on The New Yorker and Wired. We also have a paywall for some specialty content at Golfdigest.com.

The Vanity Fair paywall is built in house, with some help from outside vendors for metering.

We make extensive use of our CDN (Fastly) and VCL. Our site is in React. The New Yorker makes heavy use of VCL whereas Vanity Fair reworked its implementation to do some things in the client and some at the edge.

I'd say this is the start of a monetization conversation, not the end. Micropayments certainly have promise, but the move from print subscriptions to print and digital subscriptions needs to play out first before the next iteration. Will that be micropayments? I wouldn't close that door, but think there are likely other first steps.

Much of the business logic from the paywall originates from our previous properties. This isn't to say that it's done, but that we used those as a starting point for this implementation.

Thanks for the questions!

My team at Vanity Fair launched a paywall today. Any comments/suggestions?

This address? http://www.mit.edu.demo.fairtread.co/

Atri (http://www.atri.me) does just this, but bypasses the sites and uses the Twitter Handles on the page as the creator of record.

Also we've been working (stopping and starting) on this problem since 2009. Here's the Hacker News post for the original implementation, In-a-Moon: https://news.ycombinator.com/item?id=586798

There was a lot of learning that went on during that time. The biggest difference in implementation though was that In-a-Moon required sites to install JavaScript snippets, and we tracked at the site level. For Atri, we're bypassing sites and going straight to individuals by looking for Twitter handles.