Maybe done right, but definitely done in the wrong place...
What if what I want is it to auto-translate where it can, clearly mark what has been translated, and offer me a quick and easy way to view the original message? (:
Please separate your financial services from your social services and run them on different devices... You'll thank me later.
Relays need some kind of system statistics and health view. Hardware resources of the system, whether the system is dedicated to the relay or shared with other services, current system load, uptime stats, etc. The more information the better to evaluate the relay.
Like maybe if you follow the original notes author you don't need to even see the reposts, just the original.
The image has to be able to fit in a block.
Increase prices?
Time for a NIP that defines an acceptable markdown set?
How would this functionally work with a user's lightning wallet? Will they get an invoice every time they try to send a note to the relay? Or is it more frictionless than that somehow? I'm personally more in favor of the monthly subscription model but you have to pay more attention to resource management and adjust pricing.
I'm working on setting up one of these as well (:
Honestly DNS makes way more sense to accomplish "domain verification" than going through a webserver....
Sure, the web is assumed to be SSL wrapped these days, but little lightweight protocols like this absolutely don't need that overhead. I don't even have a website on that domain right now, I set up Apache entirely to service my NIP-05 identifier. I feel like NIP-05 should be able to work over either protocol... Consider the day when Nostr clients are doing hundreds if not thousands of these verification requests constantly. If it's on a domain with a legit website and other services, sure, go SSL. But if not, why add all the overhead?
To be even more lightweight, I could have written a little script that listens on port 80 and only spits out this one URL with the appropriate HTTP header for CORS. No webserver required, no encryption, super lightweight.
derekross@desktop:~$ curl -I https://caughq.org/.well-known/nostr.json
curl: (7) Failed to connect to caughq.org port 443: Connection refused
derekross@desktop:~$ curl -I http://caughq.org/.well-known/nostr.json
HTTP/1.1 200 OK
Date: Sat, 04 Feb 2023 04:33:14 GMT
Server: Apache/2.4.29 (Ubuntu)
Last-Modified: Sat, 04 Feb 2023 03:42:12 GMT
ETag: "65-5f3d7954f6020"
Accept-Ranges: bytes
Content-Length: 101
Access-Control-Allow-Origin: *
Content-Type: application/json
You do have CORS setup, but like I said above, you're missing an SSL cert. Once you fix that you'll be fine. Your JSON looks correct too.
Yup, I just figured that out and enabled SSL. Works great now (:
Wrong domain. That's my website. My NIP-05 Internet Identifier is druid@caughq.org (:
Figured it out. The spec requires HTTPs, and I was only serving up HTTP. Grabbed an SSL cert and enabled port 443 and it works fine.
Why would the spec require SSL encryption for essentially public information? Seems excessive...
I'm trying to get NIP-05 verification working with my domain. I read the spec, I read some tutorials, placed the JSON, enabled CORS... I'm pretty sure I've set it up correctly... But it doesn't seem to be working.
Might you glance at my profile and see if you spot what's wrong?
Using the PGP key from the keyservers as referenced in your Twitter profile, I get a bad signature:
$ gpg --verify jimmy.msg
gpg: Signature made Fri 03 Feb 2023 04:20:45 AM AST
gpg: using RSA key C1D797BE7D105291228CD70CFAA617E32679E455
gpg: BAD signature from "Jimmy Song
Looks like the correct key:
$ gpg --list-key jimmy
pub rsa2048 2014-03-11 [SCEA]
C1D797BE7D105291228CD70CFAA617E32679E455
uid [ unknown] Jimmy Song
uid [ unknown] Jimmy Song
uid [ unknown] Jimmy Song
uid [ unknown] Jimmy Song
Not sure why GPG is saying it's a bad signature...
The purple one with an ostrich silhouette inside a gem (:
