btw. from the screenshot you seem to use the old lndhub connection. You should add a new account and use the Alby account directly - give you also a bunch of new features and probably solves this message.

On the topic of the UX of scores of 0-100 and confidence of 0-100:

The simplest UX would be a single button, like the follow button. Underneath the hood, you are leaving an attestation with a score of 100 and a confidence of 100 percent. Users will not need to know or think about what’s happening under the hood.

The next step up would be two buttons, like the follow and mute button. Underneath the hood, you are leaving an attestation with a score of 100 (follow) or 0 (mute).

The next step up would be either more buttons (e.g. scores of 0, 50, or 100) or a slider for the score, which you’d implement if users want more optionality.

Same thing for confidence: add more optionality if and when the users want it. Otherwise, don’t force them to have to make too many decisions.

I see, I was misreading the spec and was thinking it was more complex than it is. Even so, both for complexity and performance reasons it's best to keep relays very simple. A DVM would also allow you to introduce the new format with universal support, rather than only getting support from relay operators that opt-in.

And yeah, I see how other algorithms could actually compose with this. So other than the REQ update, I think this is quite good.

Most people, especially other devs, ask for centralizing features without even realizing.

Centralization like a mind-control fungus that has taken over computer science for the past 60 years and just won't go away. It's an everyday fight against our own instincts.

I keep dreaming of Cashu mints that run on Blockstream Greenlight.

Deploy and forget. Like a autonomous machine in cyberspace.

Meanwhile on xitter…

I say it often but man I love this place 💜

Never leaving!

esto es nuestro

buen día

using Obtainium to update my apps from now on ⚡️

I'm interested ☺️ have similar plans

1 and 2 levels of trust seem possible to calculate client side. any more and your dealing with too much data

I think you’re exactly right to be thinking of writes and reads separately, with writes being scattered and potentially in various formats. The heavy lifting is deciding what to do with the data, and we can be flexible in our approach: no need for everyone to use the same algo, or even to know what algos are available when creating the trust attestation.

On the topic of zaps: I think it is important to separate out in our minds the notion of PROXY INDICATORS of trust, like zaps, likes, etc, and EXPLICIT CONTEXT BASED TRUST ATTESTATIONS. No reason we can’t use both at the same time! The former exist in spades; it’s time for us to focus our attention on ways to represent the latter.

Yeah, wot is basically the same as any other content-related algorithm. Different algorithms will take different things into account, and different people will choose different algorithms, maybe by use case. That doesn't mean having data structures that are explicitly wot-focused are a bad thing, they can be a useful part of the solution. But I'm with you — if someone kind 7's all of someone's notes, that's a strong signal, and doesn't require the user to maintain anything to get the benefits.