17/URL data: draft #169

felicio · 2023-02-20T10:08:49Z

Relates to:

rymnc

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

docs/draft/17-url-data.md

felicio · 2023-02-20T10:38:19Z

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.

Co-authored-by: Aaryamann Challani <[email protected]>

John-44 · 2023-02-20T12:16:54Z

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 · 2023-02-20T12:37:07Z

@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

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 · 2023-02-20T13:41:04Z

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

felicio · 2023-02-20T13:46:28Z

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

@John-44 then,

Should feat(56/STATUS-COMMUNITIES): initial draft vacp2p/rfc#567 be placed in this repo too?
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 · 2023-02-20T13:54:39Z

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

@John-44 then,

Should feat(56/STATUS-COMMUNITIES): initial draft vacp2p/rfc#567 be placed in this repo too?

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 · 2023-02-21T03:30:00Z

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 · 2023-02-22T02:16:20Z

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 · 2023-02-23T16:59:34Z

docs/draft/17-url-data.md

+ // content and public key concatanated and sha256 hashed twice, returning first 4 bytes
+ bytes checksum = 2;


Not worth it, in my opinion. I expanded on this at status-im/status-web#345 (comment).

This demonstrates one way of preventing

you creating a new community/profile with offending content (e.g. name, description)

copying the generated share link

slapping my/mine public key at the end

and pointing others to the linka and telling them I'm the author of the content

However, if you knew my public key before hand and spent a little effort by generating the link programmatically, this wouldn't catch it. And that is also the reason why I think this checksum is NOT even worth – can't assume the data is valid.

@cammellos confirmed, replacing with a signature after # and adding corresponding field to CommunityDescription and ContactCodeAdvertisement.

@corpetty @0xc1c4da to ensure integrity of the links containing encoded data at all times we've replaced the checksum for signature.

Is it okay?

Signature was originally considered at status-im/status-web#327 (comment).

Cc @John-44

docs/draft/17-url-data.md

felicio · 2023-03-01T18:00:15Z

docs/draft/17-url-data.md

+message URLProps {
+ string encoded_url_data = 1;
+ // Signature of encoded URL data
+ string encoded_signature = 2;


ℹ️ A signature of the already encoded data so the verification does not require decoding, decompressing and deserializing.

felicio · 2023-03-01T18:04:14Z

docs/draft/17-url-data.md

+
+// Field on CommunityDescription, CommunityChat and ContactCodeAdvertisement
+message URLProps {
+ string encoded_url_data = 1;


ℹ️ Stores the url data already encoded alongside the other proto messages so clients don't have to do the additional computation for other members/communities, just mapping now.

docs/draft/17-url-data.md

felicio · 2023-05-09T18:11:33Z

Moved to vacp2p/rfc#600.

Moved from status-im/specs#169 Reference pull request: vacp2p/rfc#600 --------- Co-authored-by: Felicio Mununga <[email protected]>

add spec

9c0b4eb

felicio requested review from rymnc, cammellos and iurimatias February 20, 2023 10:11

felicio mentioned this pull request Feb 20, 2023

Link previews status-im/status-web#327

Closed

rymnc reviewed Feb 20, 2023

View reviewed changes

docs/draft/17-url-data.md Outdated Show resolved Hide resolved

docs/draft/17-url-data.md Outdated Show resolved Hide resolved

felicio and others added 2 commits February 20, 2023 11:39

Update docs/draft/17-url-data.md

94bbb51

Co-authored-by: Aaryamann Challani <[email protected]>

Update 17-url-data.md

6f2c5da

felicio mentioned this pull request Feb 21, 2023

Add url data encoding status-im/status-web#345

Merged

Update 17-url-data.md

4e654c7

felicio commented Feb 23, 2023

View reviewed changes

felicio added 4 commits February 28, 2023 11:50

Update 17-url-data.md

9f8588b

update wordlist.txt

fe22965

update doc

f068d55

update wordlist

53aeee6

felicio commented Mar 1, 2023

View reviewed changes

docs/draft/17-url-data.md Show resolved Hide resolved

felicio commented Mar 1, 2023

View reviewed changes

felicio mentioned this pull request Mar 1, 2023

18/URL scheme: draft #159

Closed

Update 17-url-data.md

c1a718a

cammellos approved these changes Mar 2, 2023

View reviewed changes

felicio commented Mar 2, 2023

View reviewed changes

docs/draft/17-url-data.md Show resolved Hide resolved

add tags

44ad67a

rename URLProps to URLParams

5a61250

felicio mentioned this pull request Mar 15, 2023

Prerelease felicio/status.app#6

Open

35 tasks

felicio closed this May 9, 2023

This was referenced May 9, 2023

feat(59/STATUS-URL-DATA): initial draft vacp2p/rfc#600

Closed

feat(60/STATUS-URL-SCHEME): initial draft vacp2p/rfc#602

Closed

felicio mentioned this pull request Jul 12, 2023

Drop signing of status.app links status-im/status-web#459

Closed

jimstir mentioned this pull request Feb 28, 2024

feat(59/STATUS-URL-DATA): initial draft vacp2p/rfc-index#13

Merged

jimstir added a commit to vacp2p/rfc-index that referenced this pull request Sep 17, 2024

feat(59/STATUS-URL-DATA): initial draft (#13)

36f64f0

Moved from status-im/specs#169 Reference pull request: vacp2p/rfc#600 --------- Co-authored-by: Felicio Mununga <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

17/URL data: draft #169

17/URL data: draft #169

felicio commented Feb 20, 2023 •

edited

Loading

rymnc left a comment

felicio commented Feb 20, 2023

John-44 commented Feb 20, 2023

felicio commented Feb 20, 2023

John-44 commented Feb 20, 2023

felicio commented Feb 20, 2023

John-44 commented Feb 20, 2023 •

edited

Loading

oskarth commented Feb 21, 2023 •

edited

Loading

felicio commented Feb 22, 2023

felicio Feb 23, 2023 •

edited

Loading

felicio Feb 28, 2023

felicio Mar 2, 2023

felicio Mar 1, 2023

felicio Mar 1, 2023

felicio commented May 9, 2023

		// content and public key concatanated and sha256 hashed twice, returning first 4 bytes
		bytes checksum = 2;

17/URL data: draft #169

17/URL data: draft #169

Conversation

felicio commented Feb 20, 2023 • edited Loading

rymnc left a comment

Choose a reason for hiding this comment

felicio commented Feb 20, 2023

John-44 commented Feb 20, 2023

felicio commented Feb 20, 2023

John-44 commented Feb 20, 2023

felicio commented Feb 20, 2023

John-44 commented Feb 20, 2023 • edited Loading

oskarth commented Feb 21, 2023 • edited Loading

felicio commented Feb 22, 2023

felicio Feb 23, 2023 • edited Loading

Choose a reason for hiding this comment

felicio Feb 28, 2023

Choose a reason for hiding this comment

felicio Mar 2, 2023

Choose a reason for hiding this comment

felicio Mar 1, 2023

Choose a reason for hiding this comment

felicio Mar 1, 2023

Choose a reason for hiding this comment

felicio commented May 9, 2023

felicio commented Feb 20, 2023 •

edited

Loading

John-44 commented Feb 20, 2023 •

edited

Loading

oskarth commented Feb 21, 2023 •

edited

Loading

felicio Feb 23, 2023 •

edited

Loading