Every week or so, the DSNP spec team meets to discuss some substantive issues in spec development. This week, we took notes so that others could follow along. We’re also going to experiment with recording it. If you would like to participate in this meeting, let me know. We’ll figure out what the right entrypoint is for you.
Attending: James, Wil, Rose, Enddy, Shannon, Alex
Topics:
- Profile Announce Type
- Timestamps in Activity Pub
- Handles updates
- Handles Update
The proposed way forward is to just use the registry as-is for betanet, but work through this issue during the beta. Use the WG structure to address. Random namespaces might be interesting. That would aid discovery without creating any larger control issues.
James says maybe we should rely on DNS for namespacing. Rose has a couple concerns with us punting to the DNS system: DNS is centralized compared to our current model and we don’t want to make reliance on intermediary namespace servers (like Mastodon). Those are valid concerns. Tolerating the centralization is a tradeoff and we have to get something for it.
Ultimately, we need to address this in a WG.
https://spec.projectliberty.io/Messages/Overview#profile
Wil says maybe handles are just for discovery. If you want the display name, you should look at the profile.
Shannon was thinking about this issue: in writing this up from the spec and looking at sample client code, she found a lot of issues when trying to reconcile the SDK and the spec. It wasn’t clear how much of the new handle registry supersedes that older work.
Wil is ok with promoting the Activity Pub profile in the spec to something more real. Shannon says the profile/displayname/avatar needs to be its own type for ease of indexing and fast finding. Everybody thinks that sounds reasonable.
Rose will add some comments to an issue on the question of granularity of indexing/tagging of types of content. See the results of that here: DIP-48 Activity Announcement Validations · Issue #48 · LibertyDSNP/spec · GitHub
Wil says we should put in the spec a section on what things should be native vs what shouldn’t (essentially this is big vs small).
Enddy clarifies: when we say “add a type” we mean two things: activity pub types (those are in the activity pub spec). We also mean a DNSP spec type. And the question is how do we represent the activity pub types in the DSNP universe. Sometimes we add a type to the DSNP spec. Sometimes we represent it in some other way (e.g. in some other data structure). Every DSNP type relates to an activity pub type or it replaces an activitypub type (due to space restrictions) or it’s something completely new.
Shannon asks what DSNP types have multiple activitypub types? Wil says Broadcast is the main one. Rose also points at activitypub create/update/tombstone message types, which we’re ignoring. If we want to add that, we could do that as a multiple acitivitypub type because you can list additional ones recursively when using those activity pub types.
- Timestamps in ActivityPub
We only have one reliable timestamp: block formation timestamp. Announcements in that block all have “the same” timestamp. Rose says it’s more a time range than a time stamp. We’ll use that block time as a default timestamp. If you specify a timestamp, we’ll make sure it’s near the block timestamp, so you can lie but noy by much. Rose suggests timestamp should be “within one block” of the block timestamp you’re in. But what if a message is delayed for some reason? What kind of limits do we want to enforce on announcing?
James says: let everybody claim whatever time they want. Give the block time, optional announcer timestamp, optional client timestamp and then on the receiving end, let the SDK make default rules. Every client can then deviate as it wants, trust times as they please, etc. IOW, we don’t need to handle this in the spec. But client-writers will want good defaults.
Rose says “hey, we do a lot of sorting by date!” Client-writers are going to want more granularity than block-level timestamps.
Wil says he’ll add an issue to specify the suggested timestamp in activitypub part of the spec and to write up some suggestions on how to handle some of that at the client and SDK levels.
Should we require a timestamp? James says yes, Rose says app writers can ignore stuff they don’t like. Shannon thinks a timestamp is useful for app-writers. Rose is fine with that. If we’re requiring that, does the announcer then have to validate the timestamp? Wil says that’s up to the announcer.