diff --git a/SWIPs/swip-draft_app_data_protocols.md b/SWIPs/swip-draft_app_data_protocols.md
new file mode 100644
index 0000000..d6498ec
--- /dev/null
+++ b/SWIPs/swip-draft_app_data_protocols.md
@@ -0,0 +1,119 @@
+---
+SWIP: <to be assigned>
+title: App data protocols
+author: Paul Le Cam (@PaulLeCam)
+discussions-to: https://beehive.ethswarm.org/swarm/channels/dappprotocols
+status: Draft
+type: Standards Track (Core, Networking, Interface)
+category: Interface
+created: 2019-08-06
+---
+
+<!--You can leave these HTML comments in your merged SWIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new SWIPs. Note that a SWIP number will be assigned by an editor. When opening a pull request to submit your SWIP, please use an abbreviated title in the filename, `SWIP-draft_title_abbrev.md`. The title should be 44 characters or less.-->
+
+## Simple Summary
+
+<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the SWIP.-->
+
+App developers shouldn't have to reinvent the wheel when building on top of Swarm.
+
+## Abstract
+
+<!--A short (~200 word) description of the technical issue being addressed.-->
+
+Apps built on top of Swarm share similar end-user needs, such as establishing contact with other users, sending messages, discovering files...
+
+This SWIP aims to define core data structures and protocols that can be implemented by any app using Swarm to support these needs.
+
+## Motivation
+
+<!--The motivation is critical for SWIPs that want to change the Swarm protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the SWIP solves. SWIP submissions without sufficient motivation may be rejected outright.-->
+
+User data is currently exploited by technology companies with little respect for privacy and security, let alone transparency about the usage they make of this data.
+Even though data is generated by the users, it is usually not owned by them but rather the service providers that have incentives to use this as a way to lock-in their users.
+
+Swarm can provide an opportunity to shift this relationship between data ownership and services using this data by allowing users to store their data directly in Swarm, and grant access to the apps and services they choose.
+The problem is then to define data formats that can be shared by different apps and services having different purposes, and protocols to ensure compatiblity and security between all the interested parties interacting with this data.
+
+Beyond end-user incentives of data ownership, shared formats and protocols can be beneficial to application and services developers as a way to get started faster with development on top of Swarm, and possibly access to existing user data.
+
+## Specification
+
+<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for the current Swarm platform and future client implementations.-->
+
+### Scope (WIP)
+
+- Should only rely on existing features of Swarm, but might evolve as new possibilities are added
+- Should be usable via a HTTP gateway
+- Should protect the user's security and privacy as much as possible, and document necessary trade-offs
+- Should define core data structures and validation methods
+- Should define custom extensions to core data structures
+- Should define protocols for data authoring and discovery accross multiple apps/devices/services and between different users
+- Should support versioning
+
+### Terminology (WIP)
+
+- Actor: human entity (person, group...)
+- Agent: code acting on behalf of an Actor (app, device, service...)
+- Resource: data accessible on Swarm
+  - File (any binary data)
+  - Entity (JSON data defined in spec)
+  - Source (single Entity or Entity feed)
+  - Publication (list of Sources)
+
+### Research areas (WIP)
+
+#### Data structure format
+
+- Should we use JSON or a binary format such as protocol buffers?
+- What about validation?
+
+#### Entities extensibility
+
+- Can we restrict the spec to limited number of core Entities while allowing for more complex Entities to be added as extensions?
+- Can we provide fallback types for complex Entities that would not be supported by a given client?
+- What about validation of unknown (non-core or from supported extensions) Entities?
+
+#### Core entities and protocols
+
+- Define what entities should be part of core vs extensions.
+- Define validation rules for these core entities.
+- Define discover and exchange rules for these entities.
+
+#### Key management
+
+- How could an Actor add and remove (revoke) Agents and Resources at will?
+- How could an Agent add and remove (if own) a Source from a Publication?
+
+#### Data encryption
+
+- Should a single algorithm or multiple ones be supported/recommended?
+- Should Swarm built-in encryption and/or ACT be used?
+
+## Rationale
+
+<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+
+TODO
+
+## Backwards Compatibility
+
+<!--All SWIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The SWIP must explain how the author proposes to deal with these incompatibilities. SWIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
+
+N/A
+
+## Test Cases
+
+<!--Test cases for an implementation are mandatory for SWIPs that are affecting changes to data and message formats. Other SWIPs can choose to include links to test cases if applicable.-->
+
+TODO
+
+## Implementation
+
+<!--The implementations must be completed before any SWIP is given status "Final", but it need not be completed before the SWIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
+
+TODO
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).