interesting, cc nostr:nprofile1qqs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8thwden5te0dehhxarj9ekh2arfdeuhwctvd3jhgtnrdakj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qxvpy4 

 Is it what occurs when I pay 10 Sats to discover popular notes from people I don't follow? 

 That's a DVM service on Amethyst's 4th tab. 

This one will be automated and global, instead of personalized for you.  

 While this is definitely needed, I have my doubts about cramping everything into one kind. Are we going to make that table huge?

For example, @LeoWandersleb wants to position himself as a reproduceable attestation service provider. He's drafted an event for this response which would be too complicated for inclusion here.

Same for WoT, it is a contentious topic and I'm not even sure what 0-100 means. The response would likely require more data than an integer.  @pippellia 

Something like the DVM NIP that uses sub-kinds might be more useful. 

 I agree. We don't need to put everything on 30382. 

What we do need is to specify what the "service" is calculating so that the user can chose which provider of that calculation they trust and clients can know what the value means.

There will be some differences between providers, but the goal and the final result spec (type, range, tags, etc) should be just one. 

Hopefully this NIP enables that multiple provider specification to come together.  

 >  final result spec (type, range, tags, etc) should be just one

Did I understand correctly - you want to include type, range, tags etc for each service into this NIP? 

 In the early days, yes. As it grows we can break it off. 

Right now we just need to start the work of specifying stuff. 

 nostr:nprofile1qqsvfa085adgecmg84ffelcxx6zrn3ffu5jrc6cjtwng0zge3ptv43cpz9mhxue69uhkummnw3ezuamfdejj7qgcwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tcwmah2e 

 Looks like this if for trusted providers of a given service as opposed to the ability to signal 'I believe this specific thing x to be true'.

So, nostr:nprofile1qqsra2ey033mkdwl5w8q0jss9ak69zafh82xsuvhwsaauw3trkq2amgpz9mhxue69uhkummnw3ezuamfdejj7qgcwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tck28qzu could be a trusted provider of Proof of Place Assertions (using this NIP); however the Assertion itself would need to be signalled elsewhere, perhaps a different Attestation NIP.

Did I get that right? 

 You can def do Place scores and things like that. I don't know what other assertions it would need to be signalled, but it could be added.  

 See the Attestations section here:

nostr:naddr1qq2nya2z2akk6j60w9jz6vpeweg4vn2g8pvrqq3qcn670f663n3ks02jnnlsvd5y88zjnefy8343ykaxs7y3nzzketrsxpqqqp65wstzn6c 

 The Attestation Provider and the Attestation itself are distinct. 

 Nice! Yeah, it feels like BTC Map can attest for who currenctly controls each place in this PR. We just need to create a new kind with the d-tag equals to the identifier of the place. That event would then have a "result" field with the pubkey of the current owner.

Or maybe the opposite, the event's d-tag is the user and BTC Map lists the locations that user owns.  

 so it's a NIP-78 version of the settings app, here's the choice of a service for this purpose, why do you need trust? 

 Hum.. it has nothing to do with NIP-78 because it is not client-based. 

Its more like relay lists: you just select a few for the app to use. 

Trust is needed because they are doing the calculation for you and there is no way to check if the calculation was done correctly. 

 I don't understand how it's different, choose a host image service, Proxy user media, cache, and this would be a service to calculate your followers, zap and WoT. 

 That's correct. But none of those settings are saved on NIP-78. They have been generalized to be used by any client.  

 I just added a "Common Topics" idea that will just bring up the common topics each of us write about and allow clients to display in each user's profile. 

This could become a really cool NIP, with lots of real value-adds by decentralized services out there.
nostr:nevent1qqswhw3c4l60tcpvv99ul576akq9m3zwhhest00slutuqk8d8vea7uspzemhxue69uhkummnw3ex2mrfw3jhxtn0wfnj7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqzdrmup7 

 Always growing. That is one of our super powers.
nostr:nevent1qqswhw3c4l60tcpvv99ul576akq9m3zwhhest00slutuqk8d8vea7uspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygzxpsj7dqha57pjk5k37gkn6g4nzakewtmqmnwryyhd3jfwlpgxtspsgqqqqqqsqh3t22 

 Wen Proof-of-Doctor? 👀

Cc: @Nathan Day  @BenGunn 

 been thinking about this too ... esp when there's so many npub keys pretending to be a well known handle. 

Would this be a service that someone use pay to be validated by? Sort of like how how https://ens.domains were popular for a while there in the ETH world?   

 Regarding kind 10040:
Shouldn’t you rather be able to declare multiple relays where you can pick up the results?