ryan29 (u/ryan29) - Readit News

ryan29 commented on Show HN: Recall: Give Claude memory with Redis-backed persistent context npmjs.com/package/@joseai... · Posted by u/elfenleid

daxfohl · 2 months ago

I'm surprised Anthropic doesn't offer something like this server-side, with an API to control it. Seems like it'd be a lot more efficient than having client manually reworking the context and uploading the whole thing.

ryan29 · 2 months ago

Who should own the context?

Imagine having 20 years of context / memories and relying on them. Wouldn't you want to own that? I can't imagine pay-per-query for my real memories and I think that allowing that for AI assisted memory is a mistake. A person's lifetime context will be irreplaceable if high quality interfaces / tools let us find and load context from any conversation / session we've ever had with an LLM.

On the flip side of that, something like a software project should own the context of every conversation / session used during development, right? Ideally, both parties get a copy of the context. I get a copy for my personal "lifetime context" and the project or business gets a copy for the project. However, I can't imagine businesses agreeing to that.

If LLMs become a useful tool for assisting memory recall there's going to be fighting over who owns the context / memories and I worry that normal people will lose out to businesses. Imagine changing jobs and they wipe a bunch of your memory before you leave.

We may even see LLM context ownership rules in employment agreements. It'll be the future version of a non-compete.

ryan29 commented on Linkwarden: FOSS self-hostable bookmarking with AI-tagging and page archival linkwarden.app/... · Posted by u/FireInsight

daniel31x13 · 8 months ago

Hello everyone, I’m the main developer behind Linkwarden. Glad to see it getting some attention here!

Some key features of the app (at the moment):

- Text highlighting

- Full page archival

- Full content search

- Optional local AI tagging

- Sync with browser (using Floccus)

- Collaborative

Also, for anyone wondering, all features from the cloud plan are available to self-hosted users :)

ryan29 · 8 months ago

I'd be interested to hear your thoughts on having a PWA vs regular mobile apps since it looks like you started with a PWA, but are moving to regular apps. Is that just a demand / eyeballs thing or were there technical reasons?

ryan29 commented on Linkwarden: FOSS self-hostable bookmarking with AI-tagging and page archival linkwarden.app/... · Posted by u/FireInsight

dennisy · 8 months ago

I love these sorts of apps, but I still am not really sure why I need the webpages. At any time I do research for a topic I find more things than I can read in that session, so what are the old links for?

I would love to hear how people use this product once they have stored the links!

ryan29 · 8 months ago

I've used https://historio.us since 2011 and still pay for it to keep access to all the pages I've archived over the years. The price has been kept low enough that I can't bring myself to cancel it even though I've been using self-hosted https://archivebox.io/ for the last few years.

I always include an archived link whenever I reference something in documentation. That's my main use at the moment.

However, I also feel like I've gotten a lot of really good value when trying to learn a new development topic. Whenever I find something that looks like it might be useful, I archive it and, because everything is searchable, I end up with a searchable index of really high quality content once I actually know what I'm doing.

I find it hard to rediscover content via web search these days and there's so much churn that having a personal archive of useful content is going to increase in value, at least in my opinion.

ryan29 commented on Zoom outage caused by accidental 'shutting down' of the zoom.us domain status.zoom.us/incidents/... · Posted by u/RVRX

agwa · 8 months ago

You omitted key portions of that section. Here's the full quote (emphasis added):

> The foregoing requirements of this Section 2.10(c) shall not apply for (i) purposes of determining Renewal Pricing if the registrar has provided Registry Operator with documentation that demonstrates that the applicable registrant expressly agreed in its registration agreement with registrar to higher Renewal Pricing at the time of the initial registration of the domain name following clear and conspicuous disclosure of such Renewal Pricing to such registrant

Furthermore:

> The parties acknowledge that the purpose of this Section 2.10(c) is to prohibit abusive and/or discriminatory Renewal Pricing practices imposed by Registry Operator without the written consent of the applicable registrant at the time of the initial registration of the domain and this Section 2.10(c) will be interpreted broadly to prohibit such practices

Yes, premium domains can be priced higher, but the Renewal Pricing has to be "clear and conspicuous" to the registrant at the time of initial registration. Are you aware of any litigation related to this?

ryan29 · 8 months ago

The exact pricing isn’t disclosed. All they do is tell you the price will be “higher”. Anyone registering a premium domain is getting higher than uniform renewal pricing, so whatever they’re doing right now is considered adequate and that’s just generic ToS in the registration agreement AFAIK.

It sounds like you think I’m being deceptive. Do you know about any registry premium domains where someone has a contractually guaranteed price?

Also, based on my own anecdotal experience, ICANN doesn’t interpret 2.10c broadly and they allow the registries to push the boundaries as much as they want.

ryan29 commented on Zoom outage caused by accidental 'shutting down' of the zoom.us domain status.zoom.us/incidents/... · Posted by u/RVRX

VWWHFSfQ · 8 months ago

> But why put your brand at the mercy of a government like that?

Literally every single TLD is administered by a government.

.com itself is under jurisdiction of USA and operated by Verisign

ryan29 · 8 months ago

> .com itself is under jurisdiction of USA and operated by Verisign

Barely. The NTIA gave up all their leverage over .com in 2018. The only thing the US can do at this point is let the cooperative agreement auto-renew to limit price increases.

I wouldn't be surprised if the US withdrew from the agreement altogether at this point. Then .com would fall under the joint control of ICANN and Verisign.

ryan29 commented on Zoom outage caused by accidental 'shutting down' of the zoom.us domain status.zoom.us/incidents/... · Posted by u/RVRX

jsheard · 8 months ago

> it's the same reason why I don't use .io

Dodged a bullet there given that .io is at risk of being discontinued altogether. It hasn't been decided yet, but better to not have that dangling over your head.

ryan29 · 8 months ago

It's going to be interesting to see what they do. One of the core arguments when claiming the domain industry enjoys a competitive market is that switching costs are bearable and that switching TLDs is an option if registries increase prices too much.

So ICANN has a non-trivial choice to make. Either they maintain the position that switching costs are bearable and let .io disappear, or they admit that TLD switching is impossible and save .io, which will make it hard to argue the threat of (registrants) TLD switching keeps the industry competitive.

ryan29 commented on Zoom outage caused by accidental 'shutting down' of the zoom.us domain status.zoom.us/incidents/... · Posted by u/RVRX

agwa · 8 months ago

Although the .org price caps are gone, the registry has to raise prices uniformly for all domains. They can't target popular domains for discriminatory pricing. ccTLDs can.

ryan29 · 8 months ago

> They can't target popular domains for discriminatory pricing.

That's not completely accurate. Section 2.10c of the base registry agreement says the following in relation to the uniform pricing obligations:

> The foregoing requirements of this Section 2.10(c) shall not apply for (i) purposes of determining Renewal Pricing if the registrar has provided Registry Operator with documentation that demonstrates that the applicable registrant expressly agreed in its registration agreement with registrar to higher Renewal Pricing at the time of the initial registration

Most registrars have blanket statements in their registration agreement that say premium domains may be subject to higher renewal pricing. For registry premium domains, there are no contractual limits on pricing or price discrimination. AFAIK, the registries can price premium domains however they want.

ryan29 commented on ATProto and the ownership of identity anirudh.fi/blog/identity/... · Posted by u/icy

verdverm · a year ago

There is an amount of legitimacy to the domain issue, at least to me if one considers how certain phishing attempts leverage human (lack of) observation patterns. Like if someone had a bunch of identities under goog1e.com

I see having independent, from Bluesky, and multiple methods of verification as a strength of the network and architecture.

ryan29 · a year ago

I think that once you have domains as an identity, you can solve a lot of problems with the idea of 'just add money'. If $1000 gets me a gold check mark, it changes the economics of impersonation. Is it worth it to spend $1000 to get a gold check mark on 'goog1e.com' if a brand monitoring system is going to get that moderated out of existence in a couple of hours?

That's also why domain verification systems need to have continuous re-validation with more frequent re-validation for new identities. For example, if '@goog1e.com' is a new identity, it should be re-validated after 1h, 4h, 8h, 16h (up to a maximum). Additionally, you could let other validated users with aged accounts trigger a re-validation (with shared rate limits for a target domain).

The great thing about domains is that those of us that are good faith participants can build a ton of value on them and that value can be used as a signal for trustworthiness. The hard part is conveying that value to regular users in a way that's simple to understand.

We could also have systems that use some type of collateral attestation. For example, if I donate $1000 to the EFF, maybe I could attribute that donation to my domain 'example.com' and the EFF could attest to the fact that I've spent $1000 in the name of 'example.com'.

You probably have to gate that though some type of authority, but I can imagine a system where domain registrars could do that. I would love to buy reputation from my registrar by donating money to charity.

ryan29 commented on ATProto and the ownership of identity anirudh.fi/blog/identity/... · Posted by u/icy

shrink · a year ago

I like the domain name identity model used by AT (so much so I built handles.net[1] for managing domain name based handles) but during my time reading opinions on Bluesky it has become apparent there's a lot more confusion about and distrust towards domain names amongst non-technical people than I previously thought.

I thought that people generally understood that domain names are owned and that their provenance can be independently verified (which is why they're valuable for identity) but there's a fairly large and vocal contingent of Bluesky users that are frustrated by domain names, so much so there are multiple efforts to establish a private verification system on Bluesky like verified.quest[2].

A lot of people do not want to look at and understand domain names, instead they want to see a name and a check mark. They want a central authority to tell them who is trustworthy and who is not. Domain names are a great solution for technology-adjacent people and I hope that they become more widely accepted, but I'm not too optimistic.

I am optimistic and hopeful that AT has a bright future ahead of it. I think AT has a lot going for it... but I do not think that identity will be a part of that. I suspect many apps built on AT will not bother with handles and will just use local display names.

[1] https://handles.net [2] https://verified.quest

ryan29 · a year ago

The platform owners have spent two decades de-emphasizing domains, so it's not too surprising that most people struggle to understand how they work. I think that can change with education and awareness if domains as identity start to catch on. It just takes time.

For now, I think wider adoption of things like DomainConnect [1] would make a difference. It works really well to set up an MS365 account with DNS hosted at Cloudflare, but it would need a workflow that supports sending requests to your DNS admin rather than assuming everyone is a DNS admin.

> A lot of people do not want to look at and understand domain names, instead they want to see a name and a check mark. They want a central authority to tell them who is trustworthy and who is not.

I think 'trustworthy' is a key word there and would add that I think a lot of regular people conflate identity verification with moderation. It's important to keep those separate because as soon as an identity system becomes a moderation system, it's worthless.

That's what makes domains so great for identity, especially with the way the AT protocol works. It helps to create a clear separation between identity verification and moderation. Moderation is much harder than identity verification, so having a clear line between the two should make it easier to develop technical systems that perform identity verification.

For pure identity verification, I think BIMI [2] is sitting on a solution they don't even realize they have. They're too tunnel visioned on email verification, but the system they've built with VMC (verified mark certificates) works as a decentralized system of logo verification. For example, I can tell you this logo [3] is trademarked and owned by 'cnn.com' and I can do it via technical means starting with the domain name:

    dig default._bimi.cnn.com TXT

Seeing a 3rd party URL in the TXT value makes me think the implementation is weak since that would be better as a CNAME pointing to a TXT record managed by a 3rd party, but I've never looked into the details enough to know if it'll follow CNAMEs (like ACME or DKIM do).

Also, the VMCs are only good for high value brands because CNN is paying DigiCert $1600 / year for the certificate, but, since it's just PKI, it allows anyone to put up that logo with a verified badge on the @cnn.com identity. A more accurate badge would be the registered trademark symbol [4].

Even though that only works for high value brands that own a logomark, it works extremely well and would be a great start to a system that's easier for the average person to understand because logos are a simpler concept than something abstract like domains and no one is spending the time and effort needed to get a fake VMC (if it's even possible).

The Bluesky implementation for domain verification has a long way to go though. It's very naive at the moment and doesn't even do a proper job of dealing with changes in domain ownership. In fact, almost everyone doing domain validation is doing it wrong because very few implementation do re-validation from what I've seen.

1. https://www.domainconnect.org/

2. https://bimigroup.org/

3. https://amplify.valimail.com/bimi/time-warner/I0vDrJpkRnB-ca...

4. https://en.wikipedia.org/wiki/Registered_trademark_symbol

ryan29 commented on PyPI Blog: Project Quarantine blog.pypi.org/posts/2024-... · Posted by u/miketheman

woodruffw · a year ago

This would not be meaningfully addressed by namespaces, since there's no authoritative, authenticated unique name system across indices. Two separate indices can (and will, based on what ecosystems like piwheels do[1]) advertise `foo/*`-namespaced packages, leaving installers where they are today.

(I think namespacing is a good idea regardless, if only because it eliminates artificial scarcity in a one-level namespace.)

[1]: https://www.piwheels.org/

ryan29 · a year ago

> since there's no authoritative, authenticated unique name system across indices

Domains provide a globally unique namespace and ownership can be verified automatically with domain validation. Bluesky did an ok job of it, but they didn't do anything to account for domain ownership changes and re-validation is non-existent, which is disappointing to see from the first big adopter since the oversight will eventually invite criticism.

I've wanted domain validated namespaces for 5+ years. Here's a comment I made about using domain validated namespaces in package managers a couple of years ago [1]:

---

I think one possible solution to that would be to assume namespaces can have their ownership changed and build something that works with that assumption.

Think along the lines of having 'pypi.org/example.com' be a redirect to an immutable organization; 'pypi.org/abcd1234'. If a new domain owner wants to take over the namespace they won't have access to the existing account and re-validating to take ownership would force them to use a different immutable organization; 'pypi.org/ef567890'.

If you have a package locking system (like NPM), it would lock to the immutable organization and any updates that resolve to a new organization could throw a warning and require explicit approval. If you think of it like an organization lock:

    v1:

        pypi.org/example.com --> pypi.org/abcd1234

    v2:

        pypi.org/example.com --> pypi.org/ef123456

If you go from v1 to v2 you know there was an ownership change or, at the very least, an event that you need to investigate.

Losing control of a domain would be recoverable because existing artifacts wouldn't be impacted and you could use the immutable organization to publish the change since that's technically the source of truth for the artifacts. Put another way, the immutable organization has a pointer back the current domain validated namespace:

    v1:

        pypi.org/abcd1234 --> example.com

    v2:

        pypi.org/abcd1234 --> example.net

If you go from v1 to v2 you know the owner of the artifacts you want has moved from the domain example.com to example.net. The package manager could give a warning about this and let an artifact consumer approve it, but it's less risky than the change above because the owner of 'abcd1234' hasn't changed and you're already trusting them.

---

1. https://news.ycombinator.com/item?id=32754029