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 नहीं हैं। यदि आप जिस नाम को जानते हैं वह पुराना Searx है, उस project में 2023 के बाद कोई code commit नहीं हुआ है और SearXNG उसे आगे बढ़ाता है, इसलिए आज आप जो नया instance शुरू करेंगे, वह किसी भी स्थिति में SearXNG ही होगा। SearXNG एक metasearch proxy है। आपकी query इसके पास जाती है, यह आपकी ओर से अन्य engines से पूछताछ करता है और tracking हटाकर उनके results आपको लौटा देता है। Index उन्हीं engines का होता है। Hister आपके दिए गए content से अपना index बनाता है: browser extension से capture किए गए pages, imported browser history, crawled URLs और उन directories की files जिन्हें आप इसके लिए निर्दिष्ट करते हैं। Self-hosted SearXNG instance आपको public web तक private access देता है। Hister आपको अपनी पढ़ी हुई सामग्री पर search देता है। दोनों के कार्य अलग हैं, इसलिए एक ही box पर दोनों चलाना सामान्य है। यदि आप ऐसा करते हैं, तो यह जानना उपयोगी है कि SearXNG आपकी searching का कितना हिस्सा वास्तव में छिपाता है, क्योंकि यह engines के सामने आपके IP को आपके server के IP से बदलता है, queries को स्वयं छिपाता नहीं है।

Hister, AGPLv3 (GNU Affero General Public License, version 3) या उसके बाद के संस्करण के अंतर्गत free software है। इसमें कोई telemetry नहीं है और इसे किसी cloud service की आवश्यकता नहीं है। यह guide version 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 में डेटा भेजते हैं और crawler आपके सोते समय भी काम करता रहता है।

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

तीसरा कारण infrastructure है। VPS पर पहले से public hostname और certificate मौजूद हैं। Browser extension को ऐसे network से server तक पहुँचने के लिए इनकी आवश्यकता होती है, जिस पर आपका नियंत्रण नहीं है। यही hostname और certificate server पर दूसरे काम भी करते हैं, क्योंकि openGym अपना पहला passkey उस hostname के विरुद्ध register करता है जो उस समय live होता है। इसलिए पहला account बनाने से पहले hostname और certificate तय होने चाहिए।

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

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 पंक्ति का अर्थ है कि डाउनलोड क्षतिग्रस्त या परिवर्तित हो गया है, इसलिए इसे इंस्टॉल करने के बजाय दोबारा डाउनलोड करें।

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

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 है, इसलिए unit hister अकाउंट की home directory पर निर्भर नहीं करती है। ProtectSystem=strict इस सर्विस के लिए पूरे filesystem को read-only बना देता है, यही कारण है कि ReadWritePaths को data directory का नाम देना पड़ता है। ProtectHome=yes सर्विस से /home को छिपा देता है, इसलिए /home के अंतर्गत देखी जाने वाली directory indexer को खाली दिखाई देगी। यदि आपको वहां फाइलों को index करने की आवश्यकता है, तो उस लाइन को हटा दें।

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 यह दर्शाता है कि process 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 variable से override किया जा सकता है, जिसमें separator के तौर पर दो underscores का उपयोग होता है। इसलिए, container deployment के लिए किसी mounted config file की आवश्यकता नहीं है। HISTER_ACCESS_TOKEN को compose file के बगल में एक .env फाइल में रखें। यदि आप फाइल को एडिट करना पसंद करते हैं, तो docker run --rm ghcr.io/asciimoo/hister:v0.17.0 create-config > config.yml डिफ़ॉल्ट सेटिंग्स को प्रिंट कर देता है।

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

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

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

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

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

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

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

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

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

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

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

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

Reverse proxy, TLS और firewall

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

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 का उत्तर वहीं दिया जाता है। यदि इनमें से कुछ भी अनुपस्थित है, तो ब्राउज़र को page के बजाय TLS error मिलता है और Caddy log में विफल challenge बार-बार दिखाई देता है।

इसके बाद बाकी सब कुछ बंद कर दें।

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

उस सूची में port 4433 जानबूझकर नहीं है। public hostname ही अंदर आने का एकमात्र तरीका नहीं है, और उसी loopback port पर point करने वाली एक onion service बिना किसी DNS record या किसी inbound port को खोले आपके अपने उपकरणों से आपके index तक पहुँच प्रदान करती है।

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

इंडेक्स भरना

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

Client-side extraction ही वह तकनीक है जो एक private index को संभव बनाती है। Extension किसी page को बिल्कुल वैसे ही देखता है जैसे आप उसे देखते हैं, login और rendering के बाद। इसलिए, कोई internal wiki page या paid article सही ढंग से index हो जाता है और आपके server को कभी भी 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 करें और उसे server की ओर 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 के बाद नया आया हो।

Server पर मौजूद 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 को ऐसे server की आवश्यकता होती है जो 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) वह interface है जिसका उपयोग assistant server पर tools call करने के लिए करता है। Hister इसे उसी base URL के अंतर्गत POST /mcp पर streamable HTTP transport के माध्यम से उपलब्ध कराता है और search, get_preview तथा get_history expose करता है। Authentication के लिए API के बाकी हिस्सों में उपयोग होने वाला वही bearer token इस्तेमाल होता है। यदि tool calling आपके लिए नया विषय है, तो अपना छोटा agent loop लिखना यह समझने का सबसे तेज तरीका है कि इस जैसे endpoint से assistant को वास्तव में क्या मिलता है।

{
  "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 सिंटैक्स की त्रुटि है। sudo ss -lntp | grep 4433 दिखाता है कि port का उपयोग कौन कर रहा है, और journalctl -u hister -n 50 --no-pager पार्स त्रुटि को प्रिंट करता है।

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

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

कंटेनर स्टार्टअप पर ही बंद हो जाता है। ./data पर अनुमति त्रुटि (permission error) का मतलब है कि डायरेक्टरी का स्वामित्व 1000 के अलावा किसी अन्य UID के पास है, जो कि डिफ़ॉल्ट इमेज के अंदर का अकाउंट है।

एडमिन रूट से 403 Forbidden त्रुटि। जब user handling चालू हो, तो POST /api/reindex और POST /api/cleanup केवल एडमिन के लिए होते हैं, इसलिए सामान्य अकाउंट को वहां एक्सेस करने से मना कर दिया जाता है।

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

FAQ

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

SearXNG एक metasearch proxy है: यह आपकी query को public search engines को भेजता है और tracking हटाकर परिणाम वापस लाता है, इसलिए index उन engines का ही रहता है। Hister आपके द्वारा देखे गए पृष्ठों और आपके द्वारा रखी गई फाइलों का अपना full-text index रखता है, इसलिए यह "मैंने वह कहाँ पढ़ा था" का उत्तर देता है, जबकि SearXNG "वेब क्या कहता है" का उत्तर देता है। वे अलग-अलग समस्याओं का समाधान करते हैं, और कई लोग एक ही सर्वर पर दोनों को चलाते हैं।

क्या अपनी पूरी browsing history को VPS पर रखना सुरक्षित है?

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

क्या मुझे browser extension की आवश्यकता है, या मैं केवल अपनी history import कर सकता हूँ?

Import एक बार की जाने वाली प्रक्रिया है। यह browser के अपने history database को पढ़ती है, इसलिए यह सर्वर के बजाय उस कंप्यूटर पर चलती है जिसमें browser profile मौजूद है। इसके बाद extension index को current रखती है, और यह login के पीछे के पृष्ठों को भी capture कर लेती है क्योंकि यह पृष्ठ के render होने के बाद browser में content को extract करती है। एक सामान्य setup में एक बार import करना और फिर extension का उपयोग करना शामिल है।

क्या कोई coding agent मेरे Hister index को search कर सकता है?

हाँ। Hister आपके base URL पर POST /mcp पर एक MCP (model context protocol) सर्वर है, जो search, get_preview और get_history को expose करता है। client को https://your-host/mcp पर point करें और उसमें अपने access token के साथ एक Authorization: Bearer header जोड़ें। इसके बाद agent उन documentation को search करता है जिन्हें आपने वास्तव में पढ़ा है, उसी version में जिसे आपने पढ़ा था, न कि उन परिणामों को जो आज public search engine में rank कर रहे हैं।