# Dipendra K. Shah — full public notes and articles corpus
> Dipendra K. Shah is a software engineer and application designer based in Kathmandu, Nepal, writing about software engineering, product craft, and technology.
This document contains the full text of published articles and engineering notes. Prefer each entry's canonical URL when citing it. Content may evolve; the updated date indicates the latest revision represented here.
## Building a Connected Engineering Blog with Next.js
- Canonical URL: https://www.dipendrakshah.com.np/blog/building-a-connected-engineering-blog
- Collection: Blog
- Status: reference
- Published: 2026-07-17
- Updated: 2026-07-17
- Tags: Next.js, software engineering, engineering notes, technical writing
> A current end-to-end tour of this site's Markdown publishing pipeline, connected notes, reading tools, PageRank graph, responsive discovery, subscriptions, SEO, and AI-readable outputs.
An engineering blog becomes more useful when an article is not an isolated
page. It should remain readable as ordinary prose, connect to the work around
it, expose enough structure for search engines and machine readers, and require
almost no publishing maintenance. This article documents the current system
and deliberately exercises its major features.
The boundary is intentionally simple: Markdown owns the writing, Next.js owns
the presentation, Git owns the history, and Vercel owns deployment. A small
compiler connects those responsibilities without introducing a CMS or a
second website stack.
## The publishing architecture
A note begins as local Markdown. Frontmatter supplies its stable title,
summary, dates, aliases, publication status, and tags. The build validates that
contract, resolves internal references, calculates indexes, and emits static or
server-rendered HTML alongside machine-readable representations.
```mermaid
flowchart LR
A[Obsidian or local Markdown] --> B[Public content boundary]
B --> C[Validation and link compiler]
C --> D[Next.js pages]
C --> E[Search and graph indexes]
C --> F[Feeds, sitemap, and LLM text]
D --> G[Git history]
E --> G
F --> G
G --> H[Vercel deployment]
```
Publication is explicit. A file must be inside a public collection and declare
`publish: true`; private vault material is never copied into the site. The
repository also includes a publishing command that validates notes before they
cross that boundary.
### Frontmatter is a contract
```yaml
title: "Building a Connected Engineering Blog with Next.js"
description: "How the connected publishing system works."
publish: true
status: reference
created: "2026-07-17"
updated: "2026-07-17"
tags:
- Next.js
- software engineering
aliases:
- Connected Engineering Notes
```
The three statuses describe editorial state without relying on a gardening
metaphor:
| Status | Meaning | Expected use |
| ---------- | -------------------------------------------- | ------------------------ |
| Brief | A concise observation or working idea | Quick technical findings |
| Developing | A note that is still being expanded | Active investigations |
| Reference | A complete article intended for repeated use | Durable explanations |
The quality gate rejects missing titles, malformed dates, unsafe or duplicate
routes, unresolved public wikilinks, missing images, invalid frontmatter, and
secret-like values. TypeScript, ESLint, and the production build run before a
change is published.
### The publishing command is the boundary
The private writing vault and website repository remain separate. The
repository's publishing command reads only the selected public folder and only
files with `publish: true`:
```bash
npm run publish:notes -- \
--source=/absolute/path/to/Vault/Public \
--attachments=/absolute/path/to/Vault/Attachments \
--build \
--push
```
It validates titles, aliases, paths, and wikilinks; converts Obsidian image
embeds; copies referenced attachments into hashed public asset names; removes
files from the previous publishing manifest; validates the resulting public
corpus; optionally runs the production build; and commits and pushes only the
generated notes, assets, and publishing manifest. Replacing `--build --push`
with `--check` performs a non-mutating eligibility check.
## Connections are part of the content model
Markdown links and Obsidian-style wikilinks are resolved during compilation.
For example, [Udayapur District](/travel/udayapur) resolves through its title or alias to a normal,
accessible HTML link. The target then receives a backlink automatically.
For every note $v$, the compiler records outgoing edges. Reversing them
produces backlinks:
$$
B(v) = \{u \in V \mid (u, v) \in E\}
$$
That shared index powers:
- connected notes at the end of an article;
- backlinks from notes that cite the current page;
- related entries inferred from tags and graph proximity;
- navigable internal-link previews;
- the compact and full notes graphs.
### PageRank identifies influential notes
The notes index provides **Top**, **Name**, and **Latest** sorting. Top is not a
manual editorial order: it follows PageRank over explicit internal links. For
node $v$, the iterative score is:
$$
PR(v) = \frac{1-d}{|V|} + d \sum_{u \in B(v)}
\frac{PR(u)}{L(u)}
$$
where $d = 0.85$ and $L(u)$ is the number of outgoing links from $u$. Dangling
rank is redistributed across the graph, and iteration stops after convergence.
The highest-ranked note begins at the center of the visualization; subsequent
notes settle in progressively wider reference rings.
### Girvan–Newman reveals link communities
PageRank answers which notes are influential, while Girvan–Newman answers
which notes form communities. The build calculates edge betweenness with
Brandes' algorithm, removes the most central bridge, recomputes betweenness,
and repeats until a useful number of connected components appears. Community
membership controls node color.
The full notes graph combines those results with a
physical simulation:
- PageRank controls centrality and initial order;
- Girvan–Newman communities control color;
- circle area represents article word count;
- explicit links behave like springs;
- repulsion and collision keep nodes legible;
- panning, zooming, dragging, and hover inspection remain interactive.
A compact framed graph is also embedded directly in `/notes`. Its initial
render fits every node inside the frame and expands outward from the center.
The accessible list beneath the canvas preserves every graph destination for
keyboard users and non-visual readers.
## Finding and browsing published work
Discovery is deliberately available without making the graph the only way to
navigate.
### Search, sorting, and responsive pagination
The Notes page searches titles, summaries, folders, and tags. All Posts searches
both modern notes and legacy essays. The global Cmd/Ctrl +
K palette searches notes, essays, tags, and photos from one compact
generated index; pressing / while not typing opens the same search.
Photo results retain their thumbnails rather than being reduced to generic text
rows.
Pagination follows viewport capacity:
| Collection | Mobile | Tablet | Desktop |
| ---------- | -----: | -----: | ------: |
| Notes | 4 | 6 | 8 |
| All Posts | 6 | 10 | 14 |
Filtering resets pagination to the first valid page, while URLs retain a
shareable page number.
### List and grid orientation
Every primary content collection has an accessible List/Grid switch:
- the Notes index;
- individual folders and topic pages;
- All Posts;
- latest writing on the landing page;
- Photos;
- the folder browser itself.
List mode favors scanning metadata in sequence. Grid mode gives each result a
self-contained card, similar to a compact research-note catalogue. The
orientation buttons expose `aria-pressed` state and work without hiding content
from assistive technology. Each page remembers its own choice, so changing Notes
does not alter Photos, All Posts, the landing page, or a specific folder or tag
page. Card grids use one column on mobile, two on medium screens, and three equal
columns on wide screens while remaining inside the same site body width.
Folder browsing now belongs inside Notes instead of the landing dashboard.
This keeps the home page focused on recent writing while `/notes` owns search,
folders, topics, publication status, and graph exploration.
### Photos participate in discovery
Photos are first-class search documents rather than a disconnected gallery.
Global search results include thumbnails and navigate directly to photo pages.
The Photos page has its own search and List/Grid control: grid mode provides a
visual gallery and dialog, while list mode includes the thumbnail, description,
location, engagement counts, and a permanent detail link. Photo dialogs and
detail pages expose views, one-time likes, private feedback, and native sharing
with clipboard fallback. On touch devices, a deliberate press-and-hold gesture
can share directly from the grid without first opening the dialog.
The first above-the-fold image loads eagerly for good Largest Contentful Paint;
the remaining images remain lazy. The photo search/view toolbar takes over the
top edge only after the normal site header has scrolled away.
## Technical prose renders like technical prose
The renderer supports GitHub-flavoured Markdown, mathematical notation,
language-aware code, diagrams, tables, task lists, quotations, and deep heading
structure. The output is semantic HTML rather than a client-only editor.
### Mathematics with LaTeX
Inline expressions such as $O(n \log n)$ stay within the sentence. Display
expressions use KaTeX:
$$
H(X) = -\sum_{x \in \mathcal{X}} p(x)\log_2 p(x)
$$
### Code with theme-aware highlighting
Fenced code retains its language and exposes a copy control:
```ts
type PublicationStatus = "brief" | "developing" | "reference";
function canPublish(input: { publish: boolean; status: PublicationStatus }) {
return input.publish && input.status !== "brief";
}
```
Light mode uses a paper-like surface and dark syntax. Dark mode uses an ambient
surface with light, language-aware tokens. Both keep the code distinct without
turning it into an unrelated black rectangle.
### Tables, tasks, and quotations
Tables use a complete cell grid at every viewport size, with overflow available
when technical content is wider than the reading column.
- [x] validate public metadata;
- [x] resolve wikilinks and backlinks;
- [x] calculate PageRank and communities;
- [x] generate search, feeds, sitemap, and machine-readable text;
- [x] render diagrams, mathematics, and highlighted code;
- [x] provide list and grid discovery modes;
- [ ] keep improving the writing itself.
> The publishing system should disappear during writing and become strict only
> at the boundary where private thought turns into public information.
## Reading without interface noise
Every published note omits the global site header, regardless of its collection,
so the page begins with the article itself. Collection indexes, graphs, photos,
and supporting pages retain the normal navigation. A fixed top-right reading
percentage, extracted table of contents that highlights the nearest section,
and active-heading state provide orientation without crowding the reading column
or placing a bar over the text. When the contents list is longer than its frame,
it scrolls itself to keep the current section in view on desktop and whenever the
mobile panel opens. A fixed close control returns directly to the complete Notes
index from every collection. On mobile, the table of contents collapses into a
small fixed icon beside the configurator and reading percentage; selecting a
section navigates to it and dismisses the section menu. After a contents jump,
the close control temporarily becomes a back arrow labelled with the previous
section; returning there restores the usual close action.
A neighboring reading control stays collapsed until requested. It offers the
site's default typeface plus five self-hosted reading fonts—Inter, Atkinson
Hyperlegible, Source Serif 4, Lora, and Merriweather—text sizing from 90% to
120%, left, center, right, or justified alignment, narrow or wide reading widths,
and bright or dark page tones. Choosing Site default removes the article-level
font override; the other choices persist across articles while leaving code in
its monospace typeface and keeping the document structure unchanged for browser
reader modes. Wide reading mode uses the broader article column while retaining
the desktop On this page sidebar by default. A reader can collapse that sidebar
into a compact dialog button and pin it back onto the page from inside the dialog;
the preference persists across articles.
Selecting a word or phrase in an article reveals a small **Look up** action. The
definition panel resolves site-specific terms, WordNet entries, computer-science
terms, and engineering idioms from local dictionaries, then presents every
matching source together. The selected text stays on the server that already
serves the site; lookup does not send reading activity to an external dictionary
service.
Breadcrumbs remain available across notes, folders, topics, graphs, photos, and
archive pages. On articles they describe Home → Notes → Folder → Article in
both visible navigation and `BreadcrumbList` structured data.
Each note footer includes an email-feedback action addressed to the site owner.
The generated message subject is `Feedback: `, and its body includes
the canonical note URL so feedback retains its context outside the browser.
The semantic `main`, `article`, headline, author, dates, headings, and
`articleBody` markers give browser reader modes a clean extraction target. The
same article also has a direct raw Markdown representation, so immersive readers
and machines do not need to reverse-engineer the interactive layout.
### Navigable previews
Internal references open a preview containing the target title, summary,
folder, and publication status. The entire preview is navigable, not just its
small title. Supported external references—such as
[Wikipedia's overview of hypertext](https://en.wikipedia.org/wiki/Hypertext)—
load a title, extract, description, and image, and likewise remain clickable.
## Visual system and accessibility
The default appearance for a new visitor is dark, with `#1f1e1d` as the main
canvas. Supporting cards, popovers, borders, and muted text use a warm neutral
palette rather than blue-grey black. Explicit Light, Dark, and System choices
remain available and are respected on subsequent visits.
List and grid cards use the same restrained corner radius as the primary landing
page buttons, keeping repeated content surfaces precise without making every
panel feel like a floating container.
The typography is self-hosted, including the five optional reading fonts, and
adds no external font request:
- **Inter** for interface and default reading text;
- **Roboto Mono** for dates, labels, metadata, and code-adjacent details;
- KaTeX's mathematical fonts for formulas.
The layout uses visible focus states, semantic landmarks, skip navigation,
accessible graph destinations, labelled control groups, reduced-motion rules,
and responsive content widths. Interactive flourishes never replace the normal
link or text representation.
The global header, page body, and footer share one content container and the same
responsive gutters, keeping their left and right edges aligned across notes,
indexes, graphs, photos, and supporting pages. On pages that retain the global
header, it stays in normal document flow and scrolls away instead of occupying
the viewport throughout the visit.
## SEO and machine readability
Good discovery begins with complete HTML. Each article receives a unique title
and description, canonical URL, publication and modification dates, Open Graph
and Twitter metadata, large image previews, and `TechArticle` structured data.
The sitemap and Atom feed enumerate public content, while stable headings and
internal links make the documents understandable without running the graph or
search interfaces.
The Atom feed is advertised in page metadata for automatic discovery. A
human-readable `/subscribe` page provides one-click Feedly and Inoreader links,
the raw feed, a copyable feed URL, and setup instructions for any other reader.
Machine readers receive multiple coordinated entry points:
- `robots.txt` explicitly permits major search and user-fetch agents;
- `llms.txt` describes the author and canonical collections;
- `llms-full.txt` provides the full public corpus with metadata and URLs;
- `/raw/[folder]/[slug]` provides per-article Markdown;
- every article advertises its Markdown alternate;
- the footer exposes the AI index and subscription guide as normal links.
The crawler policy covers current agents from OpenAI, Anthropic, Perplexity,
Google, Microsoft, Meta, and Apple, with a permissive fallback for other
readers. This cannot force a model to browse or cite the site, but it removes
avoidable technical barriers.
## Design references and implementation choices
Two independent sites helped clarify the product direction. [Bibek Panthi's
connected notes](https://bpanthi977.com/braindump/index.html) demonstrate the
value of backlinks, a physical link graph, lightweight static pages, and a clear
feed-subscription path. [Hugo Cisneros's Notes](https://hugocisneros.com/notes/)
show how a searchable notes index can remain calm, compact, and useful without
becoming a dashboard.
This implementation borrows those interaction principles rather than either
site's stack or visual identity. It keeps the existing Next.js application,
uses the site's own content compiler and design tokens, treats the output as a
professional engineering archive, and avoids metaphorical publication labels.
### One source, several representations
| Consumer | Representation |
| ------------- | ----------------------------------------------------------- |
| Reader | Semantic HTML, reading controls, TOC, lookup, and feedback |
| Search engine | Canonicals, JSON-LD, sitemap, metadata, and internal links |
| Feed reader | Atom entries and a human-readable subscription guide |
| Site search | Generated notes, essays, tags, and photo documents |
| Notes graph | PageRank, communities, word counts, and explicit edges |
| AI crawler | HTML, per-article Markdown, `llms.txt`, and `llms-full.txt` |
Correcting a title or adding a link updates the page, breadcrumb, search result,
graph label, backlink index, feed metadata, sitemap, and machine-readable corpus
from the same source.
## Current public routes
| Route | Purpose |
| ---------------------- | -------------------------------------------- |
| `/notes` | Search, folders, topics, statuses, and graph |
| `/notes/graph` | Full interactive notes graph |
| `/all-posts` | Unified modern and legacy archive |
| `/photos` | Searchable list/grid photo collection |
| `/photos/[id]` | Canonical photo detail and engagement page |
| `/tags/[tag]` | Topic-specific note results |
| `/raw/[folder]/[slug]` | Plain Markdown representation |
| `/search-index.json` | Generated global-search document index |
| `/robots.txt` | Search and AI crawler policy |
| `/sitemap.xml` | Search discovery index |
| `/atom` | Feed-reader representation |
| `/subscribe` | Human-readable feed subscription guide |
| `/llms.txt` | Machine-oriented site guide |
| `/llms-full.txt` | Full machine-readable public corpus |
Legacy `/knowledge` URLs permanently redirect to `/notes`, preserving old links
without keeping outdated public terminology.
## What the reader should notice
The system is broad, but the article remains the main object. Search is quick,
the table of contents is quiet, previews appear only when requested, the graph
starts fitted to its frame, and each interactive view has a normal link-based
equivalent.
This page demonstrates the system in one ordinary Markdown file: validated
metadata, aliases, publication status, headings and table of contents, LaTeX,
Mermaid, highlighted code, tables, tasks, tags, a wikilink, backlinks, related
notes, reading progress, mobile and desktop orientation, text lookup, adjustable
reading presentation, close navigation, note-specific email feedback, internal
and Wikipedia previews, structured data, responsive discovery, feed
subscription, sitemap inclusion, reader-mode semantics, and machine-readable
full text. That portability is the most important feature: the writing remains
useful even outside the site that presents it.
---
## Obsidian R2 Workflow
- Canonical URL: https://www.dipendrakshah.com.np/blog/obsidian-r2-workflow
- Collection: Blog
- Status: reference
- Published: 2026-07-17
- Updated: 2026-07-17
- Tags: blog
> How I synchronize Obsidian across devices using Cloudflare R2.
# # Obsidian R2 Workflow
This is a test article.
---
## How to write hello world program in C
- Canonical URL: https://www.dipendrakshah.com.np/notes/c-lang-hello-world-program
- Collection: Notes
- Status: developing
- Published: 2026-07-17
- Updated: 2026-07-17
- Tags: cprog, note
> small hello world in C
# Hello World in C
`int main()`
`{`
`println("Hello World";)`
`}`
---
## Udayapur District
- Canonical URL: https://www.dipendrakshah.com.np/travel/udayapur
- Collection: Travel
- Status: reference
- Published: 2026-07-14
- Updated: 2026-07-14
- Tags: Nepal, Koshi Province, travel
> An overview of Udayapur District in Koshi Province, Nepal, including its geography, population, administration, transportation, and notable destinations.
Udayapur District (Nepali: उदयपुर जिल्ला) is one of the fourteen districts of Koshi Province in eastern Nepal.
The district headquarters is Gaighat, located in Triyuga Municipality. Udayapur covers approximately 2,063 square kilometres and had a reported population of about 342,773 in 2021.
| Detail | Value |
| --- | --- |
| Province | Koshi Province |
| Headquarters | Gaighat |
| Area | 2,063 km² |
| Population | 342,773 |
| Population year | 2021 |
| Highest elevation | 2,310 m |
| Lowest elevation | 360 m |
| Telephone code | 035 |
| Time zone | UTC+05:45 |
Location and boundaries
Udayapur is bordered by several rivers, hills, and neighbouring districts:
• The Koshi River separates it from Sunsari District in the east.
• The Sun Koshi River separates it from Bhojpur and Khotang districts in the north.
• The Tawa River forms part of its western boundary with Sindhuli District.
• The Siwalik foothills separate it from Siraha and Saptari districts in the south.
Part of the Koshi Tappu Wildlife Reserve extends across the southeastern region near Udayapur, Sunsari, and Saptari.
History
Before the formation of modern Nepal, the area was associated with the Sen dynasty and the Kingdom of Chaudandi. The kingdom’s capital was located at present-day Chaudandigadhi.
The district headquarters was formerly situated at Panchawati. It was transferred to Gaighat in 1972.
Geography
Udayapur lies between the Mahabharat Range in the north and the Churiya or Siwalik Hills in the south.
These ranges meet toward the west and form the geographic setting of the Udayapur Valley. The valley is approximately 30 kilometres long and between 2 and 4 kilometres wide.
The Triyuga River drains the valley and flows eastward toward the Koshi River.
Approximately:
• 67% of the district is covered by forest.
• 28% is cultivated land.
• The remaining area includes settlements, rivers, wetlands, and other terrain.
Major rivers
Important rivers and streams include:
• Triyuga River
• Tawa River
• Vaidyanath River
• Baruwa River
• Kakaru River
• Yari River
• Bahadura River
• Rasuwa River
The Sun Koshi, Saptakoshi, and Kamala rivers also flow along or near district boundaries.
Physiographic regions
Udayapur can be divided into three main geographic regions.
Mahabharat Hills
The Mahabharat region extends southward from the Sun Koshi River and covers much of northern Udayapur.
This area contains steep slopes, rugged terrain, forests, and elevations ranging from approximately 1,100 to 2,310 metres.
Notable highland areas include:
• Lekhani
• Majhkharka
• Rautapokhari
Churiya Hills
The Churiya Hills generally range from approximately 550 to 1,100 metres in elevation.
This region includes smaller valleys and plains such as:
• Nepaltar
• Murkuchi
• Mainatar
• Bahuntar
• Bhuttar
• Hardeni
Inner Terai
The Inner Terai region lies mainly between approximately 360 and 550 metres above sea level.
Major population centres in this region include:
• Gaighat
• Katari
• Beltar
Some areas are vulnerable to river erosion and seasonal flooding.
Climate
Udayapur contains several climate zones because of its elevation differences.
Climate zone Approximate elevation Share of district
Lower tropical Below 300 m 33.7%
Upper tropical 300–1,000 m 45.9%
Subtropical 1,000–2,000 m 17.8%
Temperate 2,000–3,000 m 0.5%
Population and demographics
According to figures presented for the 2021 census, Udayapur has a culturally and linguistically diverse population.
Major communities include:
• Rai
• Chhetri
• Magar
• Tharu
• Tamang
• Kami
• Bahun
• Newar
• Danuwar
• Damai
• Sarki
Major first languages
Language Approximate share
Nepali 51.3%
Magar Dhut 11.0%
Tharu 8.0%
Chamling 6.9%
Tamang 5.5%
Maithili 3.8%
Bantawa 3.6%
Rai 1.9%
Newar 1.7%
Danuwar 1.5%
Religion
The district includes followers of several religious traditions, including:
• Hinduism
• Kirat Mundhum
• Buddhism
• Christianity
• Prakriti
• Islam
Local government
Udayapur is divided into eight local government areas:
Municipalities
1. Triyuga Municipality
2. Katari Municipality
3. Chaudandigadhi Municipality
4. Belaka Municipality
Rural municipalities
1. Udayapurgadhi Rural Municipality
2. Rautamai Rural Municipality
3. Tapli Rural Municipality
4. Limchungbung Rural Municipality
| Local level | Nepali name | Type | Population | Area (km²) | Wards |
| --- | --- | --- | ---: | ---: | ---: |
| Triyuga | त्रियुगा | Municipality | 104,375 | 547.43 | 16 |
| Katari | कटारी | Municipality | 60,168 | 424.89 | 14 |
| Chaudandigadhi | चौदण्डीगढी | Municipality | 53,537 | 283.78 | 10 |
| Belaka | बेलका | Municipality | 51,458 | 344.73 | 9 |
| Udayapurgadhi | उदयपुरगढी | Rural municipality | 28,929 | 209.51 | 8 |
| Rautamai | रौतामाई | Rural municipality | 20,418 | 204.08 | 8 |
| Tapli | ताप्ली | Rural municipality | 13,377 | 119.11 | 5 |
| Limchungbung | लिम्चुङबुङ | Rural municipality | 9,781 | 106.8 | 5 |
Political constituencies
The district is divided into:
• Two federal parliamentary constituencies
• Four provincial constituencies
Udayapur Constituency No. 1 broadly covers Triyuga, Chaudandigadhi, and Belaka.
Udayapur Constituency No. 2 broadly covers Katari, Udayapurgadhi, Rautamai, Tapli, and Limchungbung.
Transportation
Gaighat is connected to Nepal’s national road network through several highways.
Sagarmatha Highway
The Sagarmatha Highway, also designated NH-16, connects Gaighat with the East–West Highway near Kadmaha.
It also extends northward toward Khotang.
Madan Bhandari Highway
The Madan Bhandari Highway, or NH-09, connects Gaighat eastward toward Chatara through Beltar and Basaha.
Westward routes connect the district with Katari, Udayapurgadhi, and Sindhuli.
Other national highway connections in or near the district include NH-12, NH-14, and NH-20.
Notable places
Tribeni
Tribeni is located in Katari Municipality near the confluence of the Kamala, Tawa, and Dudhauli rivers.
The area attracts visitors during Maghe Sankranti, when a religious fair is traditionally held.
Rauta Pokhari
Rauta Pokhari is a religious and natural destination in Rautamai Rural Municipality.
The site contains a pond and a Mahadev temple surrounded by forested hills.
Koshi Tappu
The Koshi Tappu area is an important protected wetland and wildlife habitat near the Koshi River.
It is known for birdlife, wetlands, and the conservation of wild water buffalo.
Chaudandigadhi
Chaudandigadhi contains the remains of a historic fort associated with the former Sen kingdom.
The site is now located within Chaudandigadhi Municipality.
Waterfalls
Waterfalls mentioned among the district’s natural attractions include:
• Odari Khola Waterfall
• Khuwa Waterfall
See also
• Koshi Province
• Districts of Nepal
• Gaighat
• Triyuga Municipality
• Koshi Tappu Wildlife Reserve
• Chaudandigadhi Municipality
Source and attribution
This page is a summarized and reformatted adaptation of the Wikipedia article:
Udayapur District — Wikipedia
Wikipedia content is available under the Creative Commons Attribution-ShareAlike License. Verify demographic, administrative, and political information against current official government sources before using it in an authoritative publication.
## Publishing implementation
The architecture used to publish and connect this page is documented in
[Building a Connected Engineering Blog with Next.js](/blog/building-a-connected-engineering-blog).
---
## Ship of Theseus
- Canonical URL: https://www.dipendrakshah.com.np/wiki/ship-of-theseus
- Collection: Wiki
- Status: reference
- Published: 2026-07-18
- Updated: 2026-07-18
- Tags: shipoftheseus, thoughtexperiment
> A brief description of Ship of Theseus Thought Experiment
# The Ship of Theseus
## Overview
The Ship of Theseus is a classic thought experiment about **identity and change** over time. It asks: if every part of an object is gradually replaced, is it still fundamentally the same object?
## The Original Thought Experiment
The paradox comes from Plutarch's account of the ship sailed by the mythical hero Theseus, which the Athenians preserved for centuries as a monument. As planks rotted, they were replaced one by one with new wood — until eventually every original plank was gone.
**The core question:** Is the fully-repaired ship still the *same* ship Theseus sailed, or is it a different ship entirely?
## The Twist
A common addition sharpens the puzzle further: suppose someone collected all the *original* discarded planks and reassembled them into a second ship.
- Ship A: the continuously repaired ship, now made entirely of new parts
- Ship B: reassembled from 100% of the original materials, but never sailed as a continuous object
**Which one is the "real" Ship of Theseus?** Or are both? Or neither?
## Why It Matters
This isn't just an idle riddle — it's a lens for thinking about identity in general:
| Domain | Application |
|---|---|
| **Personal identity** | Nearly all your body's cells are replaced over ~7-10 years — are you the "same" person? |
| **Organizations** | A company with entirely new staff, leadership, and even name changes over decades |
| **Software** | Codebases where every original line has been rewritten |
| **Restoration/preservation** | Historic buildings or artifacts extensively repaired or rebuilt |
## Major Philosophical Responses
1. **Mereological essentialism** — an object's identity depends on its exact parts; change any part, it's technically a new object.
2. **Form over matter (Aristotelian view)** — identity comes from structure, function, and continuity of form, not the specific matter — so the repaired ship stays "the same."
3. **Four-dimensionalism** — objects are best understood as space-time "worms"; identity is about a continuous causal history, not a snapshot of matter.
4. **Identity as a social/linguistic convention** — "sameness" isn't an objective fact at all, but a label we assign based on convenience and context.
## Key Takeaway
The Ship of Theseus reveals that **identity is not simply about material composition** — it may depend on continuity, function, causal history, or how we *choose* to define "sameness." There's no universally agreed-upon answer, which is precisely what makes it a useful tool for probing deeper questions about persistence, change, and what makes something "itself."