HIP: LongFi Semantics #3

JayKickliter · 2019-08-16T22:36:52Z

This HIP proposes the high-level semantics of LongFi, the Helium network's wireless protocol.

refugeesus · 2019-08-21T17:51:38Z

@JayKickliter why is PHY/Link non-reliable?

JayKickliter · 2019-08-21T20:27:36Z

@JayKickliter why is PHY/Link non-reliable?

@refugeesus our current thinking is that any retry logic should live in HighFi due to the fact that hotspots can not be trusted to spend airtime on not-paid-for packets.

JayKickliter · 2019-08-21T21:50:45Z

@Vagabond

Vagabond · 2019-08-21T23:01:12Z

I can confirm this scrawl is my fault.

refugeesus · 2019-08-21T23:35:35Z

If the air time required by hotspots is negligible when exchanging data with devices ( t/x t: time x: number of device transmissions) is the reasoning still relevant? General economics would equate this fractional spend as a capital requirement factored into the price of using the network at some later stage.

refugeesus · 2019-08-22T18:34:49Z

Pulled a piece about link layer protocol from a working proposal paper. Spoke with @JayKickliter briefly about this at lunch but would like general input as well on this link layer mechanism so I can improve. What do you think @Vagabond?

https://github.com/helium/HIP/blob/rfk/lofi/link-layer-prop.pdf

To make this protocol easier to define, let's change our style from a specication to a whitepaper. We can decide later of this document should be HIP, and can also convert it into a more formal specification if desired.

fvasquez · 2019-09-09T01:34:47Z

text/0000-longfi.md

+
+> **TODO:**
+> - How many variants are needed?
+> - Can this tag serve both versioning and variant disambiguation?


I think versioning should be separate from DGK. That simplifies variant encoding and version parsing.

fvasquez · 2019-09-09T01:37:44Z

text/0000-longfi.md

+---
+**DID**
+
+Device identifier. DIDs are assigned to devices by organizations. Every hardware device in an organization _should_ have a unique DID, but sharing DIDs is not forbidden.


So an OUI combined with a DID constitute a unique device address on the network?

That's my thinking

fvasquez · 2019-09-09T02:04:00Z

text/0000-longfi.md

+Datagram kind. A tag value indicating this datagram's variant type.
+
+> **TODO:**
+> - How many variants are needed?


At the lowest level, a sensor can be thought of as a collection of registers that you can read from and write to. So I would start with Read and Write variants. Request and Response variants can be used to describe uplink and downlink communications. A short list of variants that satisfies these basic protocol requirements would include ReadRequest, WriteRequest, ReadResponse and WriteResponse DGK types. A WriteResponse is always preceded by a WriteRequest but a ReadResponse can be unsolicited for things like uplink sensor status values. Alternatively, you could define a fifth type like Status for unsolicited ReadResponse[s] if you do not want to overload the meaning of ReadResponse.

I'm not sure that is the kind of Type that should be here as it seems more relevant to Payload contents than Datagram function.

I'm not sure that is the kind of Type that should be here as it seems more relevant to Payload contents than Datagram function.

Fair enough. At the very least I think the protocol needs some way to distinguish between uplink and downlink datagrams so the network knows how to route them. That may not need to be a type encoded in the datagram. Could simply be whether the packet originated from the internet or a radio receiver.

Agreed, distinguishing uplink/downlink and/or first fragment vs not-first fragments would be good Datagram kinds.

We don't need to order fragments anymore.

Why do you need to distinguish between uplink/downlink? A device will have to query if data is available before receiving some payload. If the query returns true, the device inherently knows it is a receiver and the gateway the sender. Otherwise the direction is implied to be the other way. The only other bi-directional communication is joining acknowledgement and a full message received acknowledgement.

We don't need to order fragments anymore.

I don't think there's enough information in the spec to state this.

Why do you need to distinguish between uplink/downlink?

There is, again, not enough information to indicate that uplink/downlink could be implied.

I only propose those as potential types of Datagram kind. As the spec gets fleshed out, perhaps Datagram kind can be omitted as an explicit field.

We don't need to order fragments anymore.

Fountain codes remove this problem.

Why do you need to distinguish between uplink/downlink?

DGK is included in generic format for now.

fvasquez · 2019-09-09T04:25:14Z

text/0000-longfi.md

+### Joining
+[joining]: #joining
+
+When device starts up, it is session-less, or not connected to its organization's router. The process of establish a session is called joining.


Does joining involve the same 5-field datagram format used for sessions? If so then DGK variants may need to be defined for the joining process.

fvasquez · 2019-09-09T04:33:32Z

text/0000-longfi.md

+---
+**PAY**
+
+Datagram payload. Payload lengths depend on spreading and coding, but on their actual content. Payloads are intended to be encrypted and opaque to hotspots.


Did you mean to say "Payload lengths [do not] depend on spreading and coding ..."?

~~but~~ not

fvasquez · 2019-09-09T04:45:28Z

text/0000-longfi.md

+---
+**FP**
+
+Fingerprint. Packet brokerage between hotspots and routers depend on fingerprints. They allow a hotspot to prove to a router the hotspot has a datagram destined for that router, without divulging the datagram's payload. This ability is core to hotspots earning data credits for forwarding datagrams.


Packet brokerage gets complicated. Do we reward hotspots for forwarding duplicate packets? Do hotspots stop forwarding packets they aren't being rewarded for? I don't know the answers to these questions.

If there is no hardware link layer session, it seems you can either pay for packets until they are no longer needed, or drop duplicates and make gateways eat the cost of doing the work.

I believe the model is:

hotspots presents fingerpint (MAC) + device ID pair

router says, gimme the payload

hotspot delivers payload

router is expected to burn DCs on behalf of router

The interaction is supposed to happen quickly and with a small amount of trust; ie: the hotspot does not wait to see the transaction post before delivering the payload. The theory is that if a router continuously stiff the hotspot, the hotspot will blacklist said router.

The theory is that if a router continuously stiff the hotspot, the hotspot will blacklist said router.

Works for me but I don't think the blacklist period should be permanent. A hotspot should eventually give a router another chance to pay in the event that router's favorite hotspot goes down.

A hotspot should eventually give a router another chance to pay in the event that router's favorite hotspot goes down.

I think the key thing is that the router must say "i like that fingerprint, give me the payload" if and only if it intends on burning a DC. Just providing the fingerprint and the router ignoring or NAK'ing should not be what makes a hotspot blacklist the router.

In the case where a router has said "I like that fingerprint give me the payload" and repeatedly doesn't pay, this is pretty nefarious behavior and I think a very long or permanent blacklisting of that hotspot is in order.

In the case where a router has said "I like that fingerprint give me the payload" and repeatedly doesn't pay, this is pretty nefarious behavior and I think a very long or permanent blacklisting of that hotspot is in order.

Agreed. That is definitely bad behavior on the part of a router. So a router won't ask a hotspot for a packet payload if it already just received a packet from that same device via a different hotspot? I'm good with that.

We currently do not have any method to atomically swap credits for packets via the blockchain, so this is still all up in the air and might be unspecified.

My understanding was atomic swap is just unfeasible due to latencies, so it would be more of an untrusted microtransaction with eventual settlement.

fvasquez · 2019-09-09T05:10:57Z

text/0000-longfi.md

+## Protocol
+[protocol]: #protocol
+
+LongFi is a session-oriented protocol. However, unlike most wireless protocols which operate within a network of trusted base stations, devices in the Helium communicate _through_ untrusted hotspots. Therefore, sessions in the Helium network are between devices and routers. Sessions persist regardless of which or how many hotspots receive their packets.


So hotspots have no awareness of sessions? They merely see individual packets from devices that they forward on to their intended routers.

Are sessions mandatory for LongFi? Is there no session-less means of communication like UDP?

What about downlink communications from routers to devices? Are sessions bi-directional or are downlink sessions something different?

You need a form of a session somewhere to have any down-link. The association between connected device to hotspot target is less certain with session associated with the router, but it may be manageable. We won't know how manageable this is until this is deployed in the wild.

I believe you will need to establish a session from the device side, where they can query if a down-link packet is available or not.

Are sessions mandatory for LongFi? Is there no session-less means of communication like UDP?

From a practical standpoint, I don't think we can enforce sessions if a device/router pair decided not to; at least there's no way for us to force some a device/router pair from using the hotspots to move packets despite a lack of session. And I think your UDP analogy is really good.

That being said, I think the LongFi spec is describes a possible device/router protocol in addition to the hotspot routing protocol.

As a side-note, have we dropped LoFi/HiFi nomenclature, @JayKickliter?

have we dropped LoFi/HiFi nomenclature

Yes, at least for now. I didn't want to force the separation from the outset.

Using fountain codes, we will implicitly have sessions between routers and devices to fulfill the droplet aggregation process.

I'm curious why droplet aggregation has to be on the hotspot vs router?

If we use fountain code, reconstruction will be on the router and not on the hotspot.

I'm curious what the reasoning was though? I had dreamed up schemes where aggregation/reassembly could happen router side

That's what I thought I was saying:

Hotspot: does not do reassembly

Router: does reassembly

Or am I misreading something?

I am the one misreading something. My bad

lthiery · 2019-09-09T21:24:24Z

text/0000-longfi.md

+> - ~indended~ required to be encrypted?
+
+---
+**FP**


This was previously called MAC/HMAC. I like Fingerprint better because it's more expressive, but I know the blog post by Dal and perhaps the white paper make reference to MAC.

lthiery · 2019-09-09T21:28:43Z

text/0000-longfi.md

+> - Spreading-factor vs dwell-time vs range
+> - Initial uplink spreading factor
+
+### Downlink


Do we have two categories of devices?

Category Sync: downlink triggered only by uplink packets Category Async: devices are always on and ready to receive downlink

Or do we say everything is "sync" but that some devices have a long dwell time waiting for downlink packets. If they pulse out every 6 hours and wait for 6 hours on some channel, they're pretty much always on and this might allow for more dynamic behavior (whereas "device category" feels pretty static).

That's a good question. The expectation that a device is "always on" seems unreasonable to me. Most downlink communications are what I call WriteRequests and hence synchronous in nature because a corresponding WriteResponse is expected by the router. I did not consider how downlink communications would be triggered by uplink packets but that makes sense in an environment where devices sleep most of the time to conserve battery power.

Downlink communication will have to be initiated by a query from the device to router due to the class of device we deal with. Devices that are not dependent upon power conservation and network models which have stronger device-to-gateway association (sessions and handoff) are capable of asynchronously receiving in practice. We can't guarantee the former and explicitly do not have the latter for our devices.

lthiery · 2019-09-09T21:33:52Z

text/0000-longfi.md

+Datagram kind. A tag value indicating this datagram's variant type.
+
+> **TODO:**
+> - How many variants are needed?


I'm not sure that is the kind of Type that should be here as it seems more relevant to Payload contents than Datagram function.

fvasquez · 2019-09-10T20:08:31Z

text/0000-longfi.md

+> - Initial uplink spreading factor
+
+### Fragmentation
+[fragmentation]: #fragmentation


Based on what @refugeesus described to me in our meeting last week I believe the LDPC layer handles all message fragmentation, reassembly and retransmission.

fragmentation, reassembly, and FEC are covered by the process linked in a previous comment. No need for retransmission anymore. The paper excerpt also covers the ACK and rolling window timeout concepts needed to make the link layer mostly complete.

fvasquez

This document seems to cover uplink sessions from device to router but what about downlink sessions from router to device (eg. firmware updates). Are we choosing to punt on that for version 1 of the protocol?

fvasquez · 2019-09-12T22:27:23Z

text/0000-longfi.md

+|-----|-----|-----|-----|-----|
+
+> TODO: 
+> - Detail information on when ACK's can occur may be needed. Alternatively, should it be excluded for brevity in this doc?


I don't think ACKs should be excluded from this document. IoT developers want some guidance on what to expect from a LongFi router.

I can include it from the prior doc then.

fvasquez · 2019-09-12T22:42:12Z

text/0000-longfi.md

+> TODO: 
+> - Detail information on when ACK's can occur may be needed. Alternatively, should it be excluded for brevity in this doc?
+> - Size of fields to be included
+> - S1/S1 may be converted to sequence number?


Are S1 and S2 simply sequence numbers? If so then why are there two for each "Call" datagram? I thought LDPC didn't require sequence numbers to distinguish between droplets.

No S1 and S2 are seed numbers used for the fountain code process.

fvasquez · 2019-09-12T22:51:37Z

text/0000-longfi.md

+> - Detail information on when ACK's can occur may be needed. Alternatively, should it be excluded for brevity in this doc?
+> - Size of fields to be included
+> - S1/S1 may be converted to sequence number?
+
 @vagabond

 > TODO:
 > - diffie hellman?
 > - how long do sessions live for?


I remember @refugeesus telling me that an LDPC decoder can determine how much of a message has been received. A device can decide to terminate a session and start a new one when a download stops making progress.

Yes, see second standard deviation comment below.

fvasquez · 2019-09-12T22:54:47Z

text/0000-longfi.md

+
+#### Connection Frame 
+
+Before sending a payload, a device must broadcast identifying information and receive confirmation from a router via hotspot that it is ready to receive data. The call/response for this described above again is: 


Are super and connection frames distinct DGK types? What about "Call" and "Response" connection frames?

Yes those frames need to have distinct DGK values.

I just used "Call" and "Response" to indicate what the transmitting entity is expecting to send, and what it should expect to receive in response to its transmission. I am open to better terminology suggestions.

"Request" sounds better than "Call".

fvasquez · 2019-09-12T22:56:18Z

text/0000-longfi.md

+Datagram Key (DGK) - OUI - Device ID (DID) - Fingerprint (FP)
+
+|DGK | OUI | DID | FP | 
+|-----|-----|-----|-----|

 Sessions have a finite lifetime.


Based on what? A known timeout?

Once the second standard deviation of total payload size in addition to the payload (198% total) is collected without getting a full message, the session is terminated and it needs to be re-initiated right now. This puts a cap on chattyness of devices and gives us a fixed memory overhead required for embedded.

You maybe answered a different question @refugeesus ? I think the maximum length of a packet is after encoding is different than lifetime session, which I think @fvasquez is asking about.

I don't think we have defined lifetime of a session. It needs to be as infrequent as possible, to save on resources, but frequent enough to be secure. So it might depend on how many bytes you've sent using that session key?

I am working from payloads being collections of packets.

The total lifetime of a session, given a payload 100 bytes in length, is 198 bytes collected or the maximum amount of time it would take to send this amount of data.

Unique session key per ACK'ed payload sounds expensive as I mention here #3 (comment)

fvasquez · 2019-09-12T23:14:06Z

text/0000-longfi.md

+> - Detail information on when ACK's can occur may be needed. Alternatively, should it be excluded for brevity in this doc?
+> - Size of fields to be included
+> - S1/S1 may be converted to sequence number?
+


I know they're a pain but UML sequence diagrams might help others visualize session message flow.

yeah....

I'll get to it then

Vagabond · 2019-09-12T23:34:14Z

text/0000-longfi.md

+Device identifier. DIDs are assigned to devices by organizations. Every hardware device in an organization _should_ have a unique DID, but sharing DIDs is not forbidden.
+
+> TODO:
+> - Can DIDs really be shared?


From our perspective, we don't care if organizations want to do weird things with DIDs.

Vagabond · 2019-09-12T23:35:03Z

text/0000-longfi.md

+Datagram payload. Payload lengths depend on spreading and coding, but on their actual content. Payloads are intended to be encrypted and opaque to hotspots.
+
+> **TODO:**
+> - ~indended~ required to be encrypted?


Again, we don't care what organizations want to do. They probably should encrypt the information but it's not required. Imagine open networks of weather stations, etc.

Vagabond · 2019-09-12T23:40:02Z

text/0000-longfi.md

+|-----|-----|-----|-----|-----|-----|
+| X | X | X | X | X | X |
+
+Once the device receives a complete super frame structure (has been assigned a session ID) it is considered connected and can begin transmitting data frames.


I would suggest that the device allocate the session ID and make the acknowledgement optional so devices can be 'fire and forget'

If you give one-shot transmissions a different DGK value the optional ack is implied and session ID (which should probably be the last field) can be ignored.

I think your definition of session ID is different then what I was understanding previously from @Vagabond

My previous understand, you might "connect" and create a session ID once a day let's say, and then use that key to send every packet during the day, with or without ACKs.

From what you're writing, it sounds like anything that's not fire and forget requires a unique session key which expires after the payload is sent. Which sounds expensive to me...

lthiery · 2019-09-12T23:55:36Z

text/0000-longfi.md

+
+#### Connection Frame 
+
+Before sending a payload, a device must broadcast identifying information and receive confirmation from a router via hotspot that it is ready to receive data. The call/response for this described above again is: 


This definition puts a minimum level of quality of service that I find excessive. You have to be able to cheaply YOLO out a packet if you don't care about guaranteed delivery.

See #3 (comment)

lthiery · 2019-09-13T00:02:44Z

text/0000-longfi.md

+
+Super frames contain necessary connection information and requested payload size needed to facilitate communication. The added fields are: Session ID (SID), Payload Size (PLS). The generic super frame structure is as follows:
+
+|DGK | OUI | DID | FP | SID | PLS |


I think we need to start distinguishing LoFi and HiFi frames. This looks like it's more or less a HiFi frame definition, but I don't think we've done a good job of distinguishing from LoFi frames yet.

What I'm thinking need to be made clear is:

DKG, OUI, DID, FP are transparent to the hotspot

SID, PLS, etc are encrypted and opaque to the hotspot

whether a superframe is initiating a session or during a session should be opaque, or at least, not the concern of the hotspot

We have abandoned LoFi/HiFi definitions. This is all link layer information.

I'm not sure any of these fields need to be encrypted, or opaque to the hotspot.

Super frames only initiate sessions or are wrapping a one-shot transmission. The hotspot doesn't do anything but relay this information to router.

I'm not sure any of these fields need to be encrypted, or opaque to the hotspot.

I know we abandoned them but this is where the distinction is helpful. LoFi is transparent and HiFi is opaque to the hotspot.

lthiery · 2019-09-13T00:04:55Z

text/0000-longfi.md

+Datagram Key (DGK) - OUI - Device ID (DID) - Fingerprint (FP)
+
+|DGK | OUI | DID | FP | 
+|-----|-----|-----|-----|

 Sessions have a finite lifetime.


You maybe answered a different question @refugeesus ? I think the maximum length of a packet is after encoding is different than lifetime session, which I think @fvasquez is asking about.

I don't think we have defined lifetime of a session. It needs to be as infrequent as possible, to save on resources, but frequent enough to be secure. So it might depend on how many bytes you've sent using that session key?

JayKickliter · 2019-09-18T16:50:21Z

Oops. I accidentally merged @Vagabond's branch into master instead of mine

helium#336

#336

Create XXXX-subdao-onboarding-fees.md

JayKickliter added the WIP label Aug 16, 2019

JayKickliter changed the title ~~hip: LongFi Semantics~~ HIP: LongFi Semantics Aug 16, 2019

JayKickliter force-pushed the jsk/longfi branch 9 times, most recently from b978e10 to 89e1c70 Compare August 21, 2019 17:49

JayKickliter force-pushed the jsk/longfi branch from 89e1c70 to e50a1c8 Compare August 22, 2019 00:05

JayKickliter force-pushed the jsk/longfi branch from e50a1c8 to 3bc700b Compare August 22, 2019 18:46

Add (WIP) longfi HIP

cfc4b07

JayKickliter force-pushed the jsk/longfi branch from 3bc700b to cfc4b07 Compare August 22, 2019 21:34

JayKickliter added 2 commits August 26, 2019 16:47

longfi: switch to whitepaper style

88e6421

To make this protocol easier to define, let's change our style from a specication to a whitepaper. We can decide later of this document should be HIP, and can also convert it into a more formal specification if desired.

longfi: remove manual linebreaks as it confuses tools and editors

f84ae00

JayKickliter force-pushed the jsk/longfi branch from a09bf84 to 06ad189 Compare August 29, 2019 22:32

longfi: add connection text

ef17f8d

JayKickliter force-pushed the jsk/longfi branch from 06ad189 to ef17f8d Compare August 30, 2019 21:47

JayKickliter added 2 commits August 30, 2019 14:57

longfi: add fragmentation seed-text

9c4be1b

longfi: show device <-> hotspot relationship

e030bbc

JayKickliter force-pushed the jsk/longfi branch from 6fdd03f to e030bbc Compare September 3, 2019 21:40

longfi: add placeholder for regulatory constraints

b449137

JayKickliter force-pushed the jsk/longfi branch from 5a15150 to b449137 Compare September 5, 2019 17:14

JayKickliter added 3 commits September 5, 2019 10:56

Update 0000-longfi.md

911d588

lingfi: add channels placeholder

e20422d

lingfi: add uplink placeholder

b82bc04

JayKickliter force-pushed the jsk/longfi branch from 2e2b687 to b82bc04 Compare September 8, 2019 21:29

longfi: add versioning placeholder

eb7f07b

fvasquez reviewed Sep 9, 2019

View reviewed changes

lthiery reviewed Sep 9, 2019

View reviewed changes

fvasquez reviewed Sep 10, 2019

View reviewed changes

refugeesus added 2 commits September 11, 2019 15:33

Update md with connection frame brief descriptions and structures

2495576

fix syntax mistakes in tables

5593c9f

fvasquez reviewed Sep 12, 2019

View reviewed changes

Vagabond reviewed Sep 12, 2019

View reviewed changes

lthiery reviewed Sep 13, 2019

View reviewed changes

longfi: fix formatting

c333cf6

JayKickliter merged commit c333cf6 into master Sep 18, 2019

fvasquez added a commit that referenced this pull request Mar 23, 2020

Renumber HIPs #2 and #3

b00ced4

fvasquez mentioned this pull request Mar 23, 2020

Renumber HIPs #2 and #3 #18

Merged

fvasquez pushed a commit that referenced this pull request Mar 23, 2020

Renumber HIPs #12 and #11 to #2 and #3 (#18)

abfef8b

shayons297 added a commit to shayons297/HIP that referenced this pull request Feb 23, 2022

2/23 Update helium#3

64aeb98

helium#336

abhay pushed a commit that referenced this pull request Feb 23, 2022

2/23 Update #3 (#368)

b65ddf4

#336

samgutentag pushed a commit that referenced this pull request Mar 16, 2023

Merge pull request #3 from ferebee/ferebee-subdao-onboarding-1

d75a557

Create XXXX-subdao-onboarding-fees.md


		#### Connection Frame

		Before sending a payload, a device must broadcast identifying information and receive confirmation from a router via hotspot that it is ready to receive data. The call/response for this described above again is:


		Super frames contain necessary connection information and requested payload size needed to facilitate communication. The added fields are: Session ID (SID), Payload Size (PLS). The generic super frame structure is as follows:

		\|DGK \| OUI \| DID \| FP \| SID \| PLS \|

HIP: LongFi Semantics #3

HIP: LongFi Semantics #3

Conversation

JayKickliter commented Aug 16, 2019 • edited Loading

refugeesus commented Aug 21, 2019

JayKickliter commented Aug 21, 2019

JayKickliter commented Aug 21, 2019

Vagabond commented Aug 21, 2019

refugeesus commented Aug 21, 2019 • edited Loading

refugeesus commented Aug 22, 2019

Choose a reason for hiding this comment

fvasquez Sep 9, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fvasquez Sep 9, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fvasquez Sep 9, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fvasquez Sep 9, 2019 • edited Loading

Choose a reason for hiding this comment

fvasquez Sep 9, 2019 • edited Loading

Choose a reason for hiding this comment

JayKickliter Sep 9, 2019 • edited Loading

Choose a reason for hiding this comment

fvasquez Sep 9, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fvasquez Sep 9, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fvasquez Sep 9, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fvasquez left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

refugeesus Sep 12, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JayKickliter commented Aug 16, 2019 •

edited

Loading

refugeesus commented Aug 21, 2019 •

edited

Loading

fvasquez Sep 9, 2019 •

edited

Loading

fvasquez Sep 9, 2019 •

edited

Loading

fvasquez Sep 9, 2019 •

edited

Loading

fvasquez Sep 9, 2019 •

edited

Loading

fvasquez Sep 9, 2019 •

edited

Loading

JayKickliter Sep 9, 2019 •

edited

Loading

fvasquez Sep 9, 2019 •

edited

Loading

fvasquez Sep 9, 2019 •

edited

Loading

fvasquez Sep 9, 2019 •

edited

Loading

refugeesus Sep 12, 2019 •

edited

Loading