ssbc / private-group-spec

GNU Lesser General Public License v3.0

13 stars 2 forks source link

Use SSB URIs instead of sigil links #18

Closed Powersource closed 1 year ago

Powersource commented 1 year ago

Fixes https://github.com/ssbc/private-group-spec/issues/17

Allowed by https://github.com/ssbc/ssb-uri-spec/pull/17

Bumps this spec to v2 since it's a breaking change!

[x] finish discussion on how the group ids should look https://github.com/ssbc/ssb-uri-spec/issues/18
[x] go through files and make sure there're no sigil links left
[x] update schemas
[x] wait for spec tests to be merged and then update them https://github.com/ssbc/private-group-spec/pull/19

mixmix commented 1 year ago

This is a good improvement - great job noticing + executing @Powersource <3

:flamingo: :coconut: :1st_place_medal:

Powersource commented 1 year ago

but supporting the old way does cost something? it requires future private messaging apps to support sigil links when they in theory could be entirely free from them

mixmix commented 1 year ago

@Powersource lets go ahead with your suggestion. We need to consider how to migrate ahau gracefully but confident we can do that as we go...

Powersource commented 1 year ago

In https://github.com/ssbc/ssb-uri-spec/issues/18 we now decided to go with ssb:identity/group/<KEY> and i have done PRs for that in bfe-spec, uri-spec, and uri2 (linked in that issue)

Powersource commented 1 year ago

@mixmix new tests updated now

Powersource commented 1 year ago

@staltz

Why were classic uris introduced in that case?

As a shortcut to sigils. Other than that, classic URIs are not supposed to be in the data layer. E.g. msg.value.author in a classic message has to be a sigil @. If it's an SSB URI ssb:feed/classic/__ then signatures are going to look different, and everything else is going to break.

I'm fine with sigils still being used in the classic metadata. This spec pr is only about defining the group spec, specifically the value.content of a message.