Hister को self-host कैसे करें: अपना personal search engine

Hister क्या है, और क्या नहीं है

Hister एक personal search engine है जिसे आप स्वयं host करते हैं। यह आपके द्वारा देखे गए पृष्ठों और आपके पास मौजूद फाइलों के full text को index करता है, और फिर आपको web interface, terminal client, HTTP API, या AI (artificial intelligence) assistant के माध्यम से उस संग्रह को खोजने की सुविधा देता है। Hister एक सवाल का जवाब देता है: मैंने वह कहाँ पढ़ा था।

अधिकांश पाठक इस विचार से SearXNG के माध्यम से परिचित होते हैं, और ये दोनों एक ही tool नहीं हैं। SearXNG एक metasearch proxy है। आपकी query उस तक जाती है, वह आपकी ओर से अन्य engines से पूछता है, और tracking हटाकर उनके परिणाम आपको वापस देता है। index उन engines का होता है। Hister आपके द्वारा दी गई सामग्री से अपना स्वयं का index बनाता है: browser extension द्वारा capture किए गए पृष्ठ, import किया गया browser history, crawl किए गए URLs, और वे फाइलें जो उन directories में हैं जिन्हें आप इसे point करते हैं। एक self-hosted SearXNG instance आपको public web तक private access देता है। Hister आपको अपनी स्वयं की reading पर search करने की सुविधा देता है। दोनों के कार्य अलग हैं, इसलिए एक ही box पर दोनों को चलाना सामान्य है।

Hister, AGPLv3 (GNU Affero General Public License, version 3) या उसके बाद के संस्करण के अंतर्गत free software है। इसमें कोई telemetry नहीं है और इसे किसी cloud service की आवश्यकता नहीं है। यह guide v0.17.0 संस्करण को pin करती है, जो 2026-07-28 को current release था। कुछ भी copy करने से पहले releases page पर current tag की जाँच करें, और फिर वहां मिलने वाले tag को pin करें।

VPS पर Hister को self-host क्यों करें

एक index तभी उपयोगी होता है जब वह पूर्ण हो, और वह तभी पूर्ण होता है जब आप पढ़ते समय सर्वर चल रहा हो। लैपटॉप दिन में आधे समय sleep mode में रहता है। उस दौरान आपके फोन पर खोली गई pages उस तक कभी नहीं पहुँचती हैं, और रात भर चलने वाला import कभी शुरू नहीं हो पाता है। एक VPS (virtual private server) हमेशा चालू रहता है, इसलिए आपके सभी उपकरण एक ही index में data भेजते हैं और आपके सोते समय भी crawler काम करता रहता है।

दूसरा कारण है separation। app section में user_handling: true सेट करने से प्रत्येक account को एक ही instance पर अपने स्वयं के credentials और document collection मिलते हैं। इस प्रकार एक सर्वर एक परिवार या छोटी टीम का data संभाल सकता है, बिना किसी के भी reading history को कोई और देख सके।

तीसरा कारण है plumbing। VPS के पास पहले से ही एक public hostname और एक certificate होता है, जिसकी आवश्यकता browser extension को तब पड़ती है जब उसे ऐसे network से सर्वर तक पहुँचना हो जिसे आप control नहीं करते हैं।

इंस्टॉलेशन का पहला तरीका: रिलीज़ बाइनरी

Hister हर प्लेटफॉर्म के लिए एक बाइनरी रिलीज़ करता है। इसे checksums फ़ाइल के साथ डाउनलोड करें और इंस्टॉल करने से पहले सत्यापित करें।

cd /tmp
curl -LO https://github.com/asciimoo/hister/releases/download/v0.17.0/hister_0.17.0_linux_amd64
curl -LO https://github.com/asciimoo/hister/releases/download/v0.17.0/hister_0.17.0_checksums.txt
sha256sum --ignore-missing -c hister_0.17.0_checksums.txt

एक सफल परिणाम में केवल hister_0.17.0_linux_amd64: OK की एक पंक्ति दिखाई देगी। FAILED पंक्ति का अर्थ है कि डाउनलोड क्षतिग्रस्त या परिवर्तित हो गया है, इसलिए इसे इंस्टॉल करने के बजाय दोबारा डाउनलोड करें।

बाइनरी इंस्टॉल करें, फिर एक सिस्टम अकाउंट और वे डायरेक्टरीज़ बनाएँ जिनका उपयोग यह करेगा।

sudo install -m 755 /tmp/hister_0.17.0_linux_amd64 /usr/local/bin/hister
sudo useradd --system --home-dir /var/lib/hister --shell /usr/sbin/nologin hister
sudo install -d -o hister -g hister -m 750 /var/lib/hister
sudo install -d -m 755 /etc/hister
sudo hister create-config /etc/hister/config.yml

create-config एक डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल लिखता है, और यह यह भी साबित करता है कि बाइनरी इस मशीन पर चल रही है। गलत आर्किटेक्चर के लिए किया गया डाउनलोड यहीं पर cannot execute binary file: Exec format error के साथ विफल हो जाएगा।

उन कुछ सेटिंग्स को संपादित करें जो महत्वपूर्ण हैं। उत्पन्न फ़ाइल का बाकी हिस्सा वैसा ही रहने दें।

app:
  directory: /var/lib/hister
  access_token: 'paste-a-long-random-string-here'
server:
  address: 127.0.0.1:4433
  base_url: https://hister.example.com

openssl rand -hex 32 के साथ टोकन उत्पन्न करें। फ़ाइल में अब एक क्रेडेंशियल मौजूद है, इसलिए सर्विस शुरू होने से पहले इसे प्रतिबंधित (restrict) करें।

sudo chown root:hister /etc/hister/config.yml
sudo chmod 640 /etc/hister/config.yml

इसे systemd के अंतर्गत चलाएं

/etc/systemd/system/hister.service लिखें:

[Unit]
Description=Hister personal search engine
After=network-online.target
Wants=network-online.target

[Service]
User=hister
Group=hister
Environment=HISTER_CONFIG=/etc/hister/config.yml
ExecStart=/usr/local/bin/hister listen
Restart=on-failure
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/var/lib/hister

[Install]
WantedBy=multi-user.target

HISTER_CONFIG कॉन्फ़िगरेशन पाथ के लिए प्रलेखित environment variable है, इसलिए यूनिट hister अकाउंट की होम डायरेक्टरी पर निर्भर नहीं करती है। ProtectSystem=strict इस सर्विस के लिए पूरे फाइलसिस्टम को read-only बना देता है, इसीलिए ReadWritePaths को डेटा डायरेक्टरी का नाम देना आवश्यक है। ProtectHome=yes सर्विस से /home को छिपा देता है, इसलिए /home के अंतर्गत देखी जाने वाली डायरेक्टरी इंडेक्सर को खाली दिखाई देगी। यदि आपको वहां फाइलों को इंडेक्स करने की आवश्यकता है, तो उस लाइन को हटा दें।

sudo systemctl daemon-reload
sudo systemctl enable --now hister
systemctl status hister --no-pager
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:4433/

पिछले कमांड द्वारा प्रिंट किया गया कोई भी HTTP status code यह दर्शाता है कि प्रोसेस listening मोड में है। curl: (7) Failed to connect का अर्थ है कि यह listening मोड में नहीं है, और journalctl -u hister -n 50 --no-pager इसका कारण बताएगा।

इंस्टॉल करने का दूसरा तरीका: Docker Compose

यह इमेज GitHub container registry पर पब्लिश की गई है, जिसमें प्रत्येक release के लिए एक tag उपलब्ध है।

services:
  hister:
    image: ghcr.io/asciimoo/hister:v0.17.0
    container_name: hister
    user: '1000:1000'
    restart: unless-stopped
    environment:
      - HISTER__SERVER__ADDRESS=0.0.0.0:4433
      - HISTER__SERVER__BASE_URL=https://hister.example.com
      - HISTER__APP__ACCESS_TOKEN=${HISTER_ACCESS_TOKEN}
    volumes:
      - ./data:/hister/data
    ports:
      - 127.0.0.1:4433:4433

प्रत्येक configuration key में HISTER__<SECTION>__<KEY> के आकार का environment override होता है, जिसमें separator के रूप में दो underscores का उपयोग किया जाता है। इसलिए, container deployment के लिए किसी mounted config file की आवश्यकता नहीं होती है। HISTER_ACCESS_TOKEN को compose file के बगल में एक .env file में रखें। यदि आप किसी file को edit करना पसंद करते हैं, तो docker run --rm ghcr.io/asciimoo/hister:v0.17.0 create-config > config.yml डिफ़ॉल्ट मानों को प्रिंट करता है।

ऊपर दी गई दो पंक्तियों में गलती करना आसान है, और दोनों को समझना आवश्यक है।

Container के अंदर का पता 0.0.0.0:4433 होना चाहिए। एक container का अपना network namespace होता है, इसलिए वहां 127.0.0.1 पर bind की गई process केवल उस container के अंदर से ही पहुंच योग्य होती है, और published port के पास forward करने के लिए कुछ नहीं होता है।

Published port को 127.0.0.1:4433:4433 के रूप में लिखा जाता है, न कि 4433:4433 के रूप में। Docker अपने स्वयं के netfilter rules डालकर ports को publish करता है, और उन rules का मूल्यांकन ufw rules से पहले किया जाता है। इसलिए, एक साधारण 4433:4433 उस सर्वर पर भी इंटरनेट से पहुंच योग्य रहता है जहां ufw status यह दिखाता है कि port बंद है। Host side को 127.0.0.1 पर bind करने से reverse proxy ही अंदर आने का एकमात्र रास्ता रह जाता है। यही समस्या सर्वर पर मौजूद हर container पर लागू होती है, और Docker Compose on a VPS इस विषय के बाकी पहलुओं को कवर करता है।

डिफ़ॉल्ट इमेज UID 1000 और GID 1000 के रूप में चलती है, इसलिए ./data उस account द्वारा writable होना चाहिए, अन्यथा container startup के समय permission error के साथ रुक जाएगा। sudo chown -R 1000:1000 ./data इसे ठीक करता है। यदि ये संख्याएं आपके लिए नई हैं, तो पहले which UID and GID a container writes files as पढ़ें।

व्यक्तिगत सर्च इंडेक्स को expose करना सबसे खतरनाक क्यों है

Hister डिफ़ॉल्ट रूप से 127.0.0.1:4433 पर listen करता है, और यह डिफ़ॉल्ट जानबूझकर रखा गया है। विचार करें कि एक महीने के उपयोग के बाद इंडेक्स में क्या-क्या होता है: आंतरिक wiki पेज, इनवॉइस, लॉग-इन रहने के दौरान खोली गई support tickets, पासवर्ड रीसेट पेज, और आपके द्वारा पढ़ी गई हर अन्य चीज़ का पूरा टेक्स्ट। प्रोजेक्ट डॉक्यूमेंटेशन इसे सीधे तौर पर बताता है: "Hister आपके पूरे ब्राउज़िंग इतिहास को, पेज की सामग्री के साथ, सर्वर तक और वहां से ट्रांसमिट करता है।"

लीक हुए पासवर्ड डेटाबेस को अभी भी क्रैक करना पड़ता है। एक लीक हुआ व्यक्तिगत इंडेक्स प्लेन टेक्स्ट में होता है और पहले से ही खोजने योग्य (searchable) होता है, इसलिए इसे उस छोटे self-hosted ऐप की तुलना में कहीं अधिक सावधानी की आवश्यकता है जैसा यह दिखता है।

इससे दो तथ्य सामने आते हैं। Hister को डिफ़ॉल्ट रूप से किसी authentication की आवश्यकता नहीं होती है, इसलिए केवल एक reverse proxy का उपयोग करने से आपकी रीडिंग की एक खोजने योग्य कॉपी किसी भी ऐसे व्यक्ति के लिए उपलब्ध हो जाती है जिसे hostname पता चल जाए। MCP endpoint भी डिफ़ॉल्ट रूप से /mcp पर सर्व किया जाता है, और बिना किसी टोकन के, कोई भी क्लाइंट जो वहां तक पहुँचता है, इंडेक्स पर सर्च चला सकता है।

सेवा को पहली बार localhost से बाहर ले जाने से पहले authentication कॉन्फ़िगर करें। एक एकल उपयोगकर्ता को केवल app.access_token की आवश्यकता होती है, जो ब्राउज़र एक्सटेंशन, टर्मिनल क्लाइंट और किसी भी MCP क्लाइंट द्वारा भेजा गया एक साझा secret है। कई लोगों के लिए, user_handling: true सेट करें और अकाउंट बनाएँ:

sudo -u hister hister create-user alice --admin --config /etc/hister/config.yml

यह कमांड कम से कम 8 अक्षरों के पासवर्ड के लिए प्रॉम्प्ट करती है। प्रत्येक अकाउंट को अपने स्वयं के दस्तावेज़ और एक व्यक्तिगत API टोकन मिलता है, जिसे स्वामी प्रोफाइल पेज से या hister update-user पर --regen-token फ्लैग के साथ रीजेनरेट कर सकता है। एक नया टोकन जनरेट करने से पिछला टोकन तुरंत अमान्य हो जाता है, इसलिए उस अकाउंट का उपयोग करने वाले प्रत्येक डिवाइस को बाद में अपडेट करना पड़ता है।

app.public को तब तक न बदलें जब तक आप वास्तव में ऐसा न करना चाहते हों। Public mode बिना authentication के सर्च, प्रीव्यू, फाइल सर्विंग और MCP सर्च की अनुमति देता है, जबकि यह अभी भी राइट्स, हिस्ट्री एक्सेस और एडमिन ऑपरेशन्स को ब्लॉक रखता है।

Reverse proxy, TLS और firewall

Hister स्वयं HTTPS serve नहीं करता है, इसलिए इसके सामने TLS (transport layer security) को terminate करें। Caddy सबसे सरल विकल्प है, क्योंकि यह ACME (automatic certificate management environment) के माध्यम से स्वयं certificates का अनुरोध और नवीनीकरण करता है।

hister.example.com {
    reverse_proxy 127.0.0.1:4433
}

इसे sudo systemctl reload caddy के साथ reload करें। certificate जारी होने से पहले दो शर्तों का पूरा होना आवश्यक है: hister.example.com के लिए A record को इस सर्वर पर point करना चाहिए, और port 80 खुला होना चाहिए, क्योंकि HTTP-01 challenge का उत्तर वहीं दिया जाता है। यदि इनमें से कोई भी अनुपस्थित है, तो ब्राउज़र को पेज के बजाय TLS error मिलता है और Caddy log में विफल challenge बार-बार दिखाई देता है।

इसके बाद बाकी सभी ports को बंद कर दें।

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

उस सूची में port 4433 जानबूझकर शामिल नहीं किया गया है।

server.base_url का मिलान उस address से होना चाहिए जिसे आप ब्राउज़र में टाइप करते हैं, जिसमें scheme भी शामिल है। जब यह मेल नहीं खाता है, तो interface बिना style के text और गायब images के साथ लोड होता है, क्योंकि सर्वर अपने asset links को base_url से बनाता है और ब्राउज़र फिर उन्हें ऐसे origin से मांगता है जो उत्तर नहीं देता है। वही URL ब्राउज़र extension में भी डाला जाता है।

इंडेक्स भरना

Browser extension मुख्य डेटा संग्रहकर्ता है। इसे Mozilla Add-ons या Chrome Web Store से install करें, इसके options पेज को खोलें, server URL को https://hister.example.com पर सेट करें और access token को paste करें। इसके बाद यह आपके द्वारा देखे गए प्रत्येक पेज का title, full text, HTML और favicon capture करता है और उन्हें आपके सर्वर पर भेज देता है। Extraction client-side पर, browser के भीतर ही होता है। Extension किसी तीसरे पक्ष (third party) से संपर्क नहीं करता है, और यह केवल page favicon के लिए ही बाहरी request भेजता है।

Client-side extraction ही वह तकनीक है जो एक private index को संभव बनाती है। Extension किसी पेज को बिल्कुल वैसे ही देखता है जैसे आप उसे देखते हैं, login और rendering के बाद। इसलिए, कोई internal wiki पेज या paid article सही ढंग से index हो जाता है और आपके सर्वर को कभी भी credentials की आवश्यकता नहीं होती है। इसका अर्थ यह भी है कि आप जो कुछ भी देखते हैं, वह index के लिए एक candidate है, इसीलिए अधिक content से पहले skip rules का उपयोग किया जाता है।

Skip rules single-user install में rules.json में रहते हैं, या database में प्रति user के आधार पर होते हैं, और web interface में Rules tab इन्हें edit करने का सबसे आसान तरीका है। ये Go regular expressions हैं जिनका मिलान full URL से किया जाता है:

^https://mail\.example\.com
^https://bank\.example\.com
.*?utm_source=

^mail.example.com जैसा pattern कभी match नहीं होता, क्योंकि test की जा रही string https:// से शुरू होती है। एक trailing $ भी किसी ऐसे URL पर विफल हो जाता है जिसमें query string हो, क्योंकि matching के दौरान query parameters को बरकरार रखा जाता है।

मौजूदा history को browser के अपने database को पढ़कर import किया जाता है, इसलिए वह command उस machine पर चलती है जहाँ browser profile मौजूद है, यानी आपके laptop पर, न कि VPS पर। वहां वही binary install करें और उसे सर्वर की ओर point करें:

export HISTER_TOKEN='your-access-token'
hister import browser firefox -u https://hister.example.com -t "$HISTER_TOKEN"

Import एक resumable job के रूप में चलता है जिसका नाम browser-import-YYYY-MM-DD है, इसलिए आप इसे बीच में रोक सकते हैं और बाद में फिर से शुरू कर सकते हैं। Bookmark services भी इसी तरह import होती हैं, जिनमें Linkwarden, Karakeep, Wallabag, Linkding, Readeck और Shaarli शामिल हैं, और एक repeat import केवल वही fetch करता है जो पिछले import से नया है।

सर्वर पर मौजूद files को config में directories का नाम देकर index किया जाता है:

indexer:
  directories:
    - path: '/var/lib/hister/documents'
      label: 'documents'
      filetypes: ['pdf', 'docx', 'md', 'txt']

PDF, DOCX, Markdown, Org mode और valid UTF-8 text files को full text के रूप में पढ़ा जाता है। Photos और video इस सूची में नहीं हैं, इसलिए एक image library को ऐसे सर्वर की आवश्यकता होती है जो text के बजाय faces, places और dates को index करे, और PhotoPrism और Immich वे दो विकल्प हैं जिनकी आमतौर पर उस कार्य के लिए तुलना की जाती है। एक single page को hister index https://example.com के साथ जोड़ा जाता है। पूरी websites को अन्य tools के लिए clean text में बदलना एक अलग कार्य है, जिसे pages को clean text में बदलने वाले self-hosted crawlers द्वारा संभाला जाता है।

Search field-based है, इसलिए query language को पढ़ने में बिताए गए दस मिनट सार्थक साबित होते हैं:

"connection reset" domain:github.com added:<30d
title:(wireguard|nftables) -tutorial sort:-visits

MCP के माध्यम से अपने इंडेक्स पर कोडिंग एजेंट को पॉइंट करें

MCP (model context protocol) वह इंटरफ़ेस है जिसका उपयोग एक असिस्टेंट सर्वर पर टूल्स को कॉल करने के लिए करता है। Hister इसे POST /mcp पर उसी बेस URL के अंतर्गत, streamable HTTP ट्रांसपोर्ट के माध्यम से सर्व करता है, और search, get_preview तथा get_history को एक्सपोज़ करता है। ऑथेंटिकेशन के लिए वही bearer token उपयोग होता है जो बाकी API के लिए है।

{
  "mcpServers": {
    "hister": {
      "url": "https://hister.example.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_ACCESS_TOKEN"
      }
    }
  }
}

एक X-Access-Token हेडर Authorization के विकल्प के रूप में काम करता है।

यहाँ इसका लाभ यह है कि एजेंट क्या सर्च करता है। ओपन वेब सर्च वही परिणाम देता है जो आज रैंक कर रहे हैं, जो तेज़ी से बदलते सॉफ़्टवेयर के लिए अक्सर उस वर्शन का डॉक्यूमेंटेशन होता है जिसे आप रन नहीं कर रहे हैं। आपका अपना इंडेक्स वह पेज लौटाता है जिसे आपने पहले ही पढ़ लिया है और जिसे आपने सहेज कर रखा है, और get_preview संग्रहीत कॉपी को सर्व करता है, इसलिए मूल पेज के ऑफ़लाइन होने पर भी उत्तर सुरक्षित रहता है। यदि आप सार्वजनिक परिणाम भी चाहते हैं तो एजेंट को दोनों स्रोत दें: SearXNG द्वारा समर्थित ब्राउज़र सर्च स्किल ओपन वेब को एक अलग टूल के रूप में जोड़ती है। एक बार जब आप इनमें से एक से अधिक एंडपॉइंट्स रन कर लेते हैं, तो VPS पर MCP सर्वर होस्ट करना पढ़ना सार्थक है, क्योंकि उनमें से प्रत्येक इस एक्सपोज़र समस्या को साझा करता है।

डिस्क, बैकअप और रखरखाव

दस्तावेज़ीकरण के अनुसार एक इंडेक्स किया गया पेज लगभग 100 KB का होता है, जिसमें कंप्रेस्ड प्रीव्यू भी शामिल है, इसलिए एक लाख पेज लगभग 10 GB के बराबर होंगे। इसमें कोई कोटा सिस्टम नहीं है। दो सेटिंग्स को अक्सर एक समझ लिया जाता है: indexer.max_file_size_mb (डिफ़ॉल्ट रूप से 1 MiB) एक सिंगल वॉच की गई फ़ाइल को सीमित करता है, और server.max_batch_body_size (डिफ़ॉल्ट रूप से 40 MiB) एक API रिक्वेस्ट को सीमित करता है।

app.directory द्वारा नामित डायरेक्टरी में index.db होता है जिसमें प्रति-भाषा इंडेक्स फ़ाइलें, खातों और जॉब्स के लिए db.sqlite3, प्रीव्यू के लिए data/html/, और rules.json शामिल होते हैं। बैकअप का अर्थ है सर्विस को रोकना और उस पूरी डायरेक्टरी तथा कॉन्फ़िगरेशन फ़ाइल की एक कॉपी बनाना। hister export backup.json माइग्रेशन के लिए दस्तावेज़ों को JSON के रूप में लिखता है, और यह सर्वर बैकअप नहीं है।

रखरखाव के दो कमांड जानना उपयोगी है। hister reindex सर्च इंडेक्स को फिर से बनाता है, जो इंडेक्सर सेटिंग्स बदलने के बाद आवश्यक होता है। यदि बड़े इम्पोर्ट के दौरान मेमोरी का उपयोग बढ़ जाता है, तो indexer सेक्शन में detect_languages: false सेट करें और फिर से इंडेक्स करें। hister cleanup डिलीट करने के बाद बची हुई अनाथ (orphaned) प्रीव्यू और फ़ेविकॉन फ़ाइलों को हटा देता है।

डिलीट करना एक क्वेरी है, इसलिए इसे पहले ड्राई मोड में चलाएँ:

hister delete 'domain:example.com' --dry --verbose

यदि कोई कलेक्टर अभी भी इसे सबमिट करता है, तो डिलीट किया गया पेज वापस आ जाता है, इसलिए डिलीट करने से पहले स्किप रूल जोड़ें।

AGPLv3 केवल तभी मायने रखता है यदि आप कोड में बदलाव करते हैं। अपने लिए बिना किसी बदलाव के कॉपी चलाने पर कोई बाध्यता नहीं है। यदि आप Hister में बदलाव करते हैं और अन्य लोगों को नेटवर्क पर अपने वर्ज़न का उपयोग करने देते हैं, तो लाइसेंस के अनुसार आपको उन्हें अपना संशोधित सोर्स कोड उपलब्ध कराना होगा।

विफलता के प्रकार और दिखाई देने वाले संदेश

सर्वर स्टार्ट नहीं होता है। या तो port 4433 पहले से ही उपयोग में है, या config file में YAML syntax error है। sudo ss -lntp | grep 4433 यह दिखाता है कि कौन सा process port का उपयोग कर रहा है, और journalctl -u hister -n 50 --no-pager parse error को print करता है।

इंटरफेस लोड तो होता है लेकिन टूटा हुआ दिखता है। अव्यवस्थित टेक्स्ट और गायब इमेज का मतलब है कि server.base_url address bar में मौजूद URL से मेल नहीं खाता है। अंत में लगा slash (/) भी mismatch माना जाता है।

एक्सटेंशन कनेक्ट नहीं होता है। एक्सटेंशन में मौजूद server URL को base_url के बराबर होना चाहिए, सर्वर का चालू और अपडेटेड होना जरूरी है, और बीच में मौजूद कोई firewall बिना किसी संदेश के इसे ब्लॉक कर सकता है। Firefox एक्सटेंशन logs को सामान्य console से दूर रखता है: about:debugging#/runtime/this-firefox खोलें और Hister एक्सटेंशन का निरीक्षण करें।

कंटेनर स्टार्टअप पर ही बंद हो जाता है। ./data पर permission error का मतलब है कि directory का owner UID 1000 के अलावा कोई और है, जो कि default image के अंदर का account है।

Admin route से 403 Forbidden एरर। जब user handling चालू हो, तो POST /api/reindex और POST /api/cleanup केवल admin के लिए होते हैं, इसलिए सामान्य account को वहाँ access नहीं मिलता है।

इंपोर्ट के दौरान मेमोरी बढ़ जाती है। इसका मुख्य कारण बड़े history पर language detection का चलना है। detect_languages: false सेट करें और उसके बाद hister reindex चलाएं।

FAQ

Hister, SearXNG से किस प्रकार भिन्न है?

SearXNG एक मेटासर्च प्रॉक्सी है: यह आपकी क्वेरी को सार्वजनिक सर्च इंजनों पर भेजता है और ट्रैकिंग हटाकर परिणाम वापस लाता है, इसलिए इंडेक्स उन इंजनों का ही रहता है। Hister आपके द्वारा देखी गई पेजों और रखी गई फाइलों का अपना पूर्ण-पाठ (full-text) इंडेक्स रखता है, इसलिए यह "मैंने वह कहाँ पढ़ा था" का उत्तर देता है, जबकि SearXNG "वेब क्या कहता है" का उत्तर देता है। वे अलग-अलग समस्याओं का समाधान करते हैं, और कई लोग एक ही सर्वर पर दोनों को चलाते हैं।

क्या अपने पूरे ब्राउज़िंग इतिहास को VPS पर रखना सुरक्षित है?

केवल तभी, जब पहले एक्सपोज़र (exposure) संबंधी कार्य पूरे कर लिए जाएं। Hister डिफ़ॉल्ट रूप से 127.0.0.1:4433 पर बाइंड होता है और इसके लिए किसी प्रमाणीकरण (authentication) की आवश्यकता नहीं होती है। app.access_token या user_handling: true सेट करें, इसके सामने TLS वाला एक रिवर्स प्रॉक्सी लगाएं, और फायरवॉल पर पोर्ट 4433 को बंद रखें। आपके पढ़ने का पूर्ण-पाठ इंडेक्स सादे टेक्स्ट (plain text) में होता है, इसलिए जो कोई भी इस पोर्ट तक पहुंच जाएगा, वह बिना कुछ क्रैक किए सब कुछ पढ़ सकेगा।

क्या मुझे ब्राउज़र एक्सटेंशन की आवश्यकता है, या मैं केवल अपना इतिहास आयात (import) कर सकता हूँ?

आयात एक बार का बैकफिल है। यह ब्राउज़र के अपने इतिहास डेटाबेस को पढ़ता है, इसलिए यह सर्वर के बजाय उस कंप्यूटर पर चलता है जिसमें ब्राउज़र प्रोफ़ाइल मौजूद है। एक्सटेंशन उसके बाद इंडेक्स को अपडेट रखता है, और यह लॉगिन के पीछे के पेजों को भी कैप्चर करता है क्योंकि यह पेज रेंडर होने के बाद ब्राउज़र में सामग्री निकालता है। एक सामान्य सेटअप में एक बार आयात करना और फिर एक्सटेंशन का उपयोग करना शामिल है।

क्या कोई कोडिंग एजेंट मेरे Hister इंडेक्स को सर्च कर सकता है?

हाँ। Hister आपके बेस URL पर POST /mcp पर एक MCP (मॉडल कॉन्टेक्स्ट प्रोटोकॉल) सर्वर है, जो search, get_preview और get_history को एक्सपोज़ करता है। क्लाइंट को https://your-host/mcp पर पॉइंट करें और उसमें अपना एक्सेस टोकन रखने वाला एक Authorization: Bearer हेडर जोड़ें। इसके बाद एजेंट उस दस्तावेज़ को सर्च करता है जिसे आपने वास्तव में पढ़ा है, उसी वर्ज़न पर जिसे आपने पढ़ा था, न कि उस पर जो आज सार्वजनिक सर्च इंजन में रैंक करता है।