17/URL data: draft

[felicio]

Relates to:

• https://github.com/status-im/status-web/issues/327
• https://github.com/status-im/specs/pull/159

[felicio]

Wondering if this spec should be created in vacp2p/rfc. cc: @kaiserd

@rymnc you beat me to raising this question first 🙂, I was just editing another spec. And yeah, please let me know. I wasn't sure what the agreement was and this seemed like an obvious place.

[John-44]

Wondering if this spec should be created in vacp2p/rfc. cc: @kaiserd

@rymnc you beat me to raising this question first 🙂, I was just editing another spec. And yeah, please let me know. I wasn't sure what the agreement was and this seemed like an obvious place.

@rymnc the documentation for this URL format should be part of the Status Messaging and Status Communities protocol specs that you are currently working on :-)

[felicio]

@John-44 @rymnc to clarify, my question wasn't really about relation/linking, which it is of course somewhat related, but rather about actual placement.

Status currently has two repositories

• https://github.com/status-im/specs
• https://github.com/status-im/feature-specs

which have several WIP, but stable too, specs.

While I couldn't be more appreciative of and thankful that Vac is shaking things up and helping tremendously, I'd suggest

• merging the two above mentioned repos into one
• placing there what's really Status specific
• and making sure all client teams are on board (e.g. w/ an announcement), write up, discuss and maintain these

That it is what I wanted to clear out prior linking or making it part of something else.

[John-44]

@felicio https://github.com/status-im/specs is the correct repo for this

[felicio]

@felicio https://github.com/status-im/specs is the correct repo for this

@John-44 then,

1. Should https://github.com/vacp2p/rfc/pull/567 be placed in this repo too?
2. Would you agree with merging https://github.com/status-im/specs (implementation) and https://github.com/status-im/feature-specs (features) into one?

Cc @rymnc

[John-44]

@felicio https://github.com/status-im/specs is the correct repo for this

@John-44 then,

1. Should feat(56/STATUS-COMMUNITIES): initial draft vacp2p/rfc#567 be placed in this repo too?
2. Would you agree with merging https://github.com/status-im/specs (implementation) and https://github.com/status-im/feature-specs (features) into one?

Cc @rymnc

@rymnc as you are working on writing the missing Status Communities protocol specs and getting all the Status Messaging protocol specs up to date, are you thinking about either:

A) Planning on moving the legacy Status Messaging protocol specs (that are currently located in the https://github.com/status-im/specs repo) to a new repo as you update them, so that when you are finished the legacy https://github.com/status-im/specs repo can be deleted?

OR

B) Adding the new Status Communities protocol specs to https://github.com/status-im/specs and updating the Status Messaging protocol specs in place in this repo?

The reason I'm asking is that the Status Communities protocol specs and the Status Messaging protocol specs should be in the same place, and should not be duplicated in two different places.

I have no opinion on (and don't mind) what this single place is, as long as both the Status Communities protocol specs and the Status Messaging protocol specs eventually end up in the same place, and as long as there isn't an old out of date duplicate of the Status Messaging protocol specs hanging around anywhere.

e.g. perhaps we should use the vac rfc repo for everything, and get rid of the https://github.com/status-im/specs repo, or we could also do the other way around (use https://github.com/status-im/specs for everything)

[oskarth]

Hey everyone! Some historical context that might be useful:

status-im/specs (this repo) was our first effort to specify the Status protocol specs. With vacp2p/rfc the initial idea was to keep more generic Waku related specs in Vac RFCs, and then have Status protocol specific specs in this repo owned by the Status app teams. Since then, unfortunately keeping Status protocol specs became less of a priority for the app teams. At the same time, feature specs was seen as something that is more useful for Status app team development work, hence status-im/feature-specs. These feature specs were created by the Desktop team, and my understanding is that they do not attempt to be protocol specifications, but more about end users and to help developers build an app, as opposed to a protocol.

Since then, the need for protocol specifications has again become clear, especially when it comes to Status Communities and Messaging specs in terms of understanding its scalability, privacy etc properties. Based on this, @rymnc took over the work to specify these into Vac RFCs as "application layer specs" (they are separate from Waku base layer specs), e.g. see There have also been similar application layer specs that have been defined as Vac RFCs (tagged as follows, https://github.com/vacp2p/rfc/pull/567/files#diff-bd54c3ccca130b9f7dbd9fd6855c36e4feecae4d85ccc09709bda9fec85dd57fR7).

Based on this, I think it is safe to say that this repo is largely deprecated. With Vac RFCs we have a clear workflow for specs, and there are lot of people there who are used to working with protocol specs, so it makes more sense to keep them there. Note that this doesn't mean Status people can't be editors of these specs, and we'd encourage Status people to be editors of specs since you guys are the domain experts.

For the time being though, this is @rymnc and he is working on porting and updating the core Status messaging protocol specs from this repo (including Community spec draft) to Vac RFCs. Once this is done, it makes sense to put a notice/remove those specs in this repo to indicate that this repo isn't kept up to date.

If we consider things like URL data part of the core protocol, then this should indeed be part of the Community/Messaging protocol or one of its companion specs. If it is more of a client specific thing and it doesn't significantly impact core semantics, I think it is OK to just specify it at a user/app level as is done with feature-specs. I'd expect the feature-specs to refer to the protocol specs in terms of core semantics, and in some cases there might be some overlap with a different focus (protocol view or app/end-user view).

As for the other specs that are currently in this repo, if we consider them core protocol specs I suggest we move them to Vac RFCs too (repo owned by Vac, but anyone can be a editor/contributor), and if they are more app/user specific (some of the older specs are indeed of this form) they can be moved to feature-specs (repo by Status).

Also cc @kaiserd

[felicio]

Thank you for the much needed context. I will have this spec reviewed and if approved moved.

The following is just me expanding on what was my point of view:

not attempt to be protocol specifications, but more about end users and to help developers build an app

I looked at the latter as driving the former. The "what" and "why" to the "how". And the closer together in placement (i.e. one repo) and processes (i.e. format, wider reaching team reviews) the better for recalling, reasoning, presenting and maintaining.

took over the work to specify these

I didn't know all or most of these were to be ported.

to put a notice/remove those specs in this repo to indicate that this repo isn't kept up to date.

I thought marking those as deprecated/unmaintained/outdated first, announcing it to the teams and revising them in place would help with awareness, prevent scattering of the information and actually cultivate the habit.

[felicio]

Moved to https://github.com/vacp2p/rfc/pull/600.