(Proposed) Pre-RFC - Network push notifications

okinan · September 5, 2018, 4:54am

Forward
Hi, I’m new here, so I apologize if I get anything wrong, or am not detailed enough in any way.
I am told that @DGeddes can help me here since the RFC process is being updated.
I am also aware that this is not a v1 goal, and am fine with it being a post-v1 goal (patch?), or a v2 goal.

Motivation
I am working on an imageboard [1], and I hope that liveposting [2] can be a possibility with SAFE.

Desired features
1. Network Push Notifications

Example: A client is typing in a post form, we want the other clients to see what it’s typing.

A way to do this would be to have client A send a network push notification along with related data (PUT index 46 (containing the string “some”) of post 4262?), in which client B and C are watching for a network push notification, to then display the new post text on their display.

Questions:

How can we ensure that this doesn’t leak IP addresses or other user information in the process
How would this be achieved in safe_vault or perhaps safe_client_libs?
How can we structure an RFC to provide detailed information on a specification for this?

2. Streaming Chunks (Possibly off-topic)

Question:

I’m not entirely sure what @dirvine meant by this, so if applicable here (or needed) as a feature RFC, please clarify.
A “commit signal” was also mentioned, so perhaps having the network stream the chunks to clients without actually finalizing to the network yet, but having the network host it as mutable data until finalized?

Previous Discussion

Index
[1]: An imageboard is like a text BBS, but with images.
[2]: Liveposting is where you type in the post form, and it shows what you’re typing, only in the post form, to the other clients.

okinan · September 5, 2018, 5:04am

My apologies, I misread the README in https://github.com/maidsafe/rfcs
Please close this, I need to make an issue instead. (I thought it was the opposite way for some reason!)

rob · September 5, 2018, 5:49am

How about this be your “Proposed RFC” and see what people think and when you feel that its good enough for a RFC then do the process. It is often good to gather other people’s views and comments first so you can polish your RFC.

If you want it closed instead then just post again including @moderators

okinan · September 5, 2018, 6:11am

Okay, thank you, if this is acceptable here I’ll gladly have this be my “Proposed RFC”.
Does this mean I should close or otherwise modify my github issue?
Do I need to add anything, or is the OP good as is?

rob · September 5, 2018, 6:19am

Do put the details you will include in the RFC and any comments/explainations that you want to. Maybe remove the issue until you are ready.

okinan · September 5, 2018, 6:22am

Got it, thanks.
I’ll work on making this proposal more like the template where possible tomorrow.

DGeddes · September 5, 2018, 8:05am

Hi @okinan,

This is pretty good timing to be honest as it’s raising a question that I’ve been asking myself about where to host the “pre-RFC” discussion. My personal opinion is to have them here on the forum as, well, it’s a forum and better suited, IMHO, to the discussion format than GitHub issues. I’m keen to keep the GitHub issues as tidy as possible.

I think I’ll be putting more “guidance” on the forum here as well rather than keeping it to GH. Anyhoo, for the moment I’ve popped the text we have on GH for prepping the ground before submitting an RFC to GH here in case it helps anyone out.

More coming over the next wee while.

DG

Before creating an RFC

A hastily proposed RFC can hurt its chances of acceptance. Low quality proposals, proposals for previously rejected features, may be quickly rejected, which can be demotivating for the unprepared contributor. Laying some groundwork ahead of the RFC can make the process smoother.

Although there is no single way to prepare for submitting an RFC, it is generally a good idea to pursue feedback from other project developers beforehand to ascertain that the RFC may be desirable. Having a consistent impact on the project requires concerted effort toward consensus-building.

The most common preparations for writing and submitting an RFC include filing and discussing ideas on the RFC issue tracker, and occasionally posting “pre-RFCs” on the SAFE Dev Forum for early review.

As a rule of thumb, receiving encouraging feedback from long-standing project developers, and particularly members of the core team or existing contributors, is a good indication that the RFC is worth pursuing.

okinan · September 6, 2018, 1:40am

Okay, so I did some work on the RFC.

github.com

Chiiruno/rfcs/blob/dev/nps/text/0000-network-push-notifications/0000-network-push-notifications.md

# Network Push Notifications

- Status: proposed
- Type: new feature
- Related components: vault, client libs
- Start Date: 05-09-2018
- Discussion: (fill me in with link to RFC discussion - shepherd will complete this)
- Supersedes: N/A
- Superseded by: N/A

## Summary

In this RFC, we propose a feature which will allow APPs to send network push notifications to the SAFE network when uploading content, optionally with a unique indentifier specific to this notification.  
APPs can then optionally watch for these notifications, which must contain an array of pointers to the uploaded chunks on the network, and use this data.  
This will allow dynamic user-generated content service, between different APPS in live-time, in an APP-friendly way.

## Conventions

- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119).

This file has been truncated. show original

okinan · September 9, 2018, 7:26am

I added a corner case.
Would it be okay if I requested a review from one of you?
I need to know if there’s anything that needs to be added/modified, or if it’s acceptable in it’s current state.

DGeddes · September 10, 2018, 8:25am

Hi @okinan,
Are you in a rush for this - I’m slammed at the moment and won’t have time today and probably tomorrow. Can you wait a couple of days for me?
DG.

okinan · September 10, 2018, 11:08am

Not at all, please take your time.

DGeddes · September 17, 2018, 3:15pm

Hi @okinan,

Hope your weekend was good.

I’ve had an initial look at your proposal and my gut feeling is that it’s a little light. I’ve got no real input or suggestions at the moment but I’ll have a think and get back to you tomorrow if I can get some notes down.

Ta,
DG.