(Proposed) Pre-RFC - Network push notifications


#1

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.


#2

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!)


#3

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


#4

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?


#5

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.


#6

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


#7

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.


#9

Okay, so I did some work on the RFC.


#10

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.


#11

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.


#12

Not at all, please take your time.


#13

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.