This site explains the architecture and history of .NET weblog engines for readers who maintain, migrate or study self-hosted publishing systems. It covers storage, feeds, publishing protocols, URLs, templates, interaction, federation and operations. It is editorially and operationally independent from every project discussed.
This site is an independent reference on .NET blogging engines. It is not affiliated with, endorsed by, or connected to the dasBlog project, DasBlog Core, or its maintainers. The dasBlog project lives at github.com/poppastring/dasblog-core.
Why this scope
Blog engines are small enough to understand as complete systems and old enough to reveal what survives technical change. A single publication can cross framework generations, operating systems, storage models and themes while its readers continue to expect the same links and feed entries. That makes weblog software a useful lens for durable web architecture.
The site focuses on concepts that transfer between engines. The storage comparison discusses authority, backup and recovery. The feed reference treats syndication as an API. The URL guide explains why an address becomes part of an entry's identity. Hosting and migration pages connect those decisions to operations.
How dasBlog is handled
dasBlog is a significant example within this subject and is discussed by name where the history requires it. The early project-era documentation provides factual context about its BlogX lineage, BSD licence, section structure and named technical credits. The active DasBlog Core repository is used for current, high-level facts about the living project.
This domain does not function as the project's home, manual, download location or support channel. It does not reproduce a project logo, README, FAQ, release notes, source code or setup and configuration directions. The historical documentation URL contains a retrospective about how the older site was organized, not replacement documentation.
Editorial principles
- Architecture over promotion. Comparisons describe where systems place state and responsibility; they do not rank named products.
- Stable sources. External links point to standards bodies, official technical documentation or the current project repository.
- No invented precision. Unverified statistics, release claims, quotations and identifiers are excluded.
- Historical restraint. Named people appear only in narrow factual context supported by the project-era record or a current first-party source.
- Durable links. Internal URLs use a declared canonical form and deliberately avoid broad catch-all behavior.
What you will not find
There is no contact form, mailing address, email address, phone number, commercial transaction or support promise. There are no installers or package links. This is also not a general blogging magazine: its subject is the technical design of .NET and file-oriented weblog systems, not writing advice, marketing or monetization.
Maintenance policy
Because protocols and active projects evolve, current claims should remain narrow and point to first-party sources. Historical statements stay tied to their period rather than being rewritten as current instructions. Structural changes to this site should preserve its canonical URLs, the explicit independence notice and the retrospective framing of the documentation path.
Corrections should remove unsupported precision instead of replacing it with another guess. The aim is a compact reference whose claims can be checked and whose boundaries are obvious.
The reference favors durable standards and first-party project material. Links are selected for explanatory value, not affiliation, promotion or implied endorsement.
Suggested reading paths
For historical context, start with the .NET engine timeline. For an implementation-neutral tour, read storage, templates, feeds and publishing APIs. For a working publication, read permalinks, self-hosting and migration together. For newer distribution models, pair RSS and Atom with WebFinger and ActivityPub.