How are u running it? Bare metal? Docker?

So nginx, traffic, and cloudflare are both reverse proxies that can do SSL termination. Now cloudflare hijacks all SSL connection it proxies (essentially a mitm) and has configuration for if u would like SSL connection from cloudflare to ur own server.

All reverse proxies pass along headers to backend services indicating all sorts of things most importantly the remote client IP, and info about if the service is behind an ssl proxy.

I use client -> cloudflare -> nginx -> my services. The client makes an encrypted pipe between itself and cloudflare, cloudflare then terminates SSL does some scanning on the raw unencrypted packet makes an encrypted connection to nginx and attaches headers about the client. I have a SSL cert on my server where nginx does SSL termination of the cloudflare connection. Nginx then attaches more headers and does routing to passes it back to a backend service ie searxng (the service itself) the docker compose for searxng comes with a packaged traffic reverse proxie its not necessary here and will in fact cause all sorts of problems.

Here is the service in my docker compose for searxng:

searxng:
    container_name: searxng
    image: docker.io/searxng/searxng:latest
    restart: unless-stopped
    networks:
      - local_bridge
      - proxy
    volumes:
      - ./data/searxng:/etc/searxng
    environment:
      - SEARXNG_BASE_URL=https://${SEARXNG_HOSTNAME:-localhost}/
      - SEARXNG_SECRET=${SEARXNG_SECRET}
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - SETGID
      - SETUID

Here is the docker compose for my nginx config

  certbot:
    image: certbot/dns-cloudflare
    # Command to obtain certificates (run once manually or integrate with a web server's startup)
    # Replace 'yourdomain.com' and '*.yourdomain.com' with your actual domain(s)
    volumes:
      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/certbot/www:/var/www/certbot # A dummy webroot, not strictly necessary for DNS challenge but good practice
      - ./data/certbot/secrets:/etc/letsencrypt/secrets:ro # Mount secrets read-only
    command: certonly
      --dns-cloudflare
      --dns-cloudflare-credentials /etc/letsencrypt/secrets/cloudflare.ini
      --non-interactive
      --agree-tos
      --email ${LETS_ENCRYPT_EMAIL}
      --dns-cloudflare-propagation-seconds 60
      -d example.com
      -d *.example.com
    environment:
      - TERM=xterm # Required for certbot to run in non-interactive mode gracefully

  nginx:
    image: nginx:latest
    container_name: nginx
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./data/nginx/cache:/var/cache

      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/nginx.conf:/etc/nginx/nginx.conf
      
      - ./data/sites-enabled:/etc/nginx/sites-enabled
      - ./data/sites-available:/etc/nginx/sites-available
      - ./data/snippets:/config/nginx/snippets
      - ./data/www:/var/www/html

    depends_on:
      - certbot
    extra_hosts:
      - "example.com:127.0.0.1"
      - "*.example.com:127.0.0.1"

I use certbot to issue SSL certs for my domain locally this is the cert that do SSL connection between nginx and cloudflare.

Then nginx can route connection to the searxng instance (ur gonna need a bunch of nginx config and I couldn’t be bothered copy pasting that when an LLM can gen that it can probably gen all this tbh).

Also how u doing auth for searxng? Cos if ur opening it to the internet as a whole u might end up with lots of traffic from randos.

Did can be served by your own server as just a json blob or federated between multiple identity servers or on the blockchain. A did is did:source:publickey and their are multiple different sources u can use.

Someone claimed it contained hallucinations. I read through the entire thing as well as doing all the research and understanding of the concept being talked about. If someone is claiming that their are issues I expect them to be able to prove that. I’m not asking for a fact checker I’m asking for someone to provide evidence of the thing they verbatim claimed. If u wanna tell me that my research showing the sky is blue is wrong I would appreciate u pointing out my error otherwise ur just making baseless claims.

That’s exactly what I did. Its essentially a translater from 3 pages of dotpoints and notes that would be incoherent to anyone but myself to normal English.

Did also allows portable identity so ur home instance is whatever instance u feel like. Did has been tested and proven reliable its in use by lots of different applications including bluesky.

Its both. It can we a json file served from some webserver. It can be a peer hosted thing where a bunch of instances host it on your behalf. It can be something that exists on your designated identity server. It can be a transaction on a blockchain. And as long as the software knows how to resolve it they all work.

So Activpub needs an actor with an inbox and outbox to send and receive content. A did is a virtual actor that reroutes to a real actor and collects content across real actors. Ideally can send an activity to a did which is resolved to the current home instance. And the did stores ur profile picture a public key display names bio etc etc. U could use pgp as the key in the did if the devs want to support it as a cryptography protocol. The did is also used to sign each message similar to pgp. U simply need more functionality than what pgp provides

I did the research I looked at many different way to get the desired solution. I learned how ATProto works i looked into other services with did got an llm to put those ideas in the required format for the issue. Can you please point out the hallucinations in the issue so i can go and fix them

I did put effort into it I just got an LLM to write it. I’ll see what the devs say and might make an rfc if needed. And yes I’ll get an LLM to write that as well.

Yeah that’s critical without it everything would break

yep a did can be anywhere even did:nostr:publickey its part of the same system

what by having all users exist on a centralised server? That sounds like vendor lock in which is exactly what federation was trying to avoid.

Due to how the fediverse works if users can be given a did so can a community. It would only migrate for services that support did but wouldn’t be all to different.

DID already exist they are a Decentralised IDentiy (DID) it is a keypair and user data so usernames, profile, bio, and a list of accounts across different instance that allows associating post comments likes etc.

im lazy i used llm to write issue and post.

That’s essentially how ATProto does it and they publish other instance actors under “also known as” in the did. that’s essentially what im proposing.

i didn’t name it that’s what its called.

we add a did to objects and keep the id the same. supporting platforms will use did old ones will carry on using id.

did is what ATProto uses this is a step in that direction

No thats the whole point of a DID. Its an existing standard that has been established to manage decentralised identity. Their exists multiple ways to handle it so a did is did:source:id where the source can be many different things blue-sky uses a group of trusted identity server, but u can use a selhosted file, the blocckchain all sorts of things. Hell u could even use bluesky u could have the same login for ATproto (bluesky) and activpub (lemmy)

Yeah but u cant see this comment from my .ee account