Summary

JSS currently creates Settings/Preferences.ttl, Settings/publicTypeIndex.ttl, and Settings/privateTypeIndex.ttl during pod creation. This is wrong — these are app-level concerns, not server responsibilities. CSS (Community Solid Server) does not create these files.

Why this is a bug

The correct approach per CSS and the Solid spec:

1. Preferences — an app creates a preferences resource and links it from the profile by updating profile/card to include:

   <#me> <http://www.w3.org/ns/pim/space#preferences> </settings.ttl> .

2. Type Indexes — apps create and manage type indexes, then link them from the WebID profile. The server has no business knowing about type registrations.

3. Discovery — apps discover preferences via the WebID profile link (pim:preferences), not by convention paths hardcoded by the server.

Current behavior

Pod creation in src/handlers/container.js generates:

• Settings/Preferences.ttl — with links to type indexes
• Settings/publicTypeIndex.ttl — empty solid:TypeIndex
• Settings/privateTypeIndex.ttl — empty solid:TypeIndex

And src/webid/profile.js embeds publicTypeIndex and privateTypeIndex links directly in the profile.

Expected behavior

• Server creates only: profile/card, ACLs, basic containers (public/, private/, inbox/)
• Apps are responsible for creating preferences and type indexes via standard LDP operations (PUT/PATCH)
• Apps link preferences from the profile via PATCH on profile/card
• Aligns with CSS behavior where preferences are standard LDP resources, not server-managed

Reference

CSS treats all resources as standard LDP resources. "Preferences" in CSS refers to HTTP content negotiation (Accept headers), not user preference storage.