Getting Started
- Quickstart
- How to use Hyperties in Applications
- How to develop new Hyperties
- How to develop new Protostubs
- How to develop new Idp Proxies
- Interworking Protostubs for Chat
- Interworking Protostubs for WebRTC
- How to develop Message Nodes
- reTHINK Core Framework implementation
Concepts
- Conceptual Foundations
- Hyper-linked Entities - Hyperties
- Decentralized Messaging
- Protocol on-the-fly
- P2P Data Synchronization
- Decentralized Trust
- Reference Architecture
- Communication Control Main Workflows
APIs
Messaging Framework
- Messaging Framework Overview
- Messaging Node
- Protostub specification
- P2P Message Delivery
- Message Node and Protostubs design recommendations
Runtime
Trust Management
How it Works - Basics
- Overview on reTHINK Basic Mechanisms
- Runtime Deployment
- Hyperty Deployment
- Protocol Stub Deployment
- Address Allocation
- Hyperty Registration
- Message Routing
- Routing Address Resolve for Msg Node Stubs
- Routing Address Resolve
- Intra-runtime Msg Delivery
- Inter-runtime Msg delivery
- Cross Domain Msg delivery
- P2P Msg delivery
How it Works - Data Synchronization
- P2P Data Sync Overview
- Data Object Creation
- Data Object Subscription
- Data Object Unsubscription
- Data Object Delete
- Data Object Child
- Data Sync Resume for Observers
- Data Sync Resume for Reporters
- Observer unsubscribed by Reporter
- Data Object Reporter Delegation
How it Works - Discovery
How it Works - Identity Management
- Identity Management Overview
- Identity Binding
- Id Token generation
- User identity assertion
- Domain Login
How it Works - Legacy Interworking
Testing
- Tests and Evaluation Overview
- Interoperability Evaluation
- Identity Management Evaluation
- Message Node Evaluation
Core Datamodel
Data Object Models
- Communication Data Object
- Connection Data Object
- Context Data Object
- Databackup Data Object
- Wallet Data Object
- E-commerce Data Object
- Spot Data Object
- Device Data Object
- Elearning Data Object
Messages Specification
- Messages Specification Overview
- Data Object Synchronization
- Address Allocation
- Registration
- Wallet management
- Discovery
- Identity Management
- P2P Connections Management
Backend Deployment
Standards
Use-Cases
- reTHINK Use Cases Overview
- H2H Conversation with single CSP
- H2H inter-domain Manageable Conversation
- H2H Conversation with decoupled CSP and IdP
- Always Connected with the Trusful Ones
- Dynamic Media Server or Media Gateway provisioning
- Trust
- H2H Conversation with QoS
- H2H Partial Anonymous Conversation
- H2H Multiparty Conversations
- H2H Conversation Browsing
- User Authentication and Registration
- Service Subscription
- M2M Seamless connected from different but Trustful domains
- Validation of trust
- M2M Always Connected in Trustful Domains for Multi vendor devices
- Human Context Presence Management
- Service Recommendation by Business Broker
H2H inter-domain Manageable Conversation
Actors
Alice and Bob are Identified Consumer that are Conversation Participants
Alice and Bob are subscribers of different Communication Service Providers.
Pre-conditions
-
Alice and Bob are using different CSPs, but are registered (authenticated, authorized) at the IdP of their CSP.
-
Alice knows Bob identifier
Description
Similar to H2H Conversation with single CSP but in this case Alice and Bob are subscribed to different CSPs. They are using the corresponding service behavior - user interface of their CSP (e.g. Alice conversation user experience is set by its service provider).
Differentiation - Market Relevance
Not currently possible with Web Communications. Essential to achieve seamless interoperabilty between any user without having the need to use more than one conversational App.
Remark: The above mentioned description is one option, in which each user keeps their original user experience. There is also the possibility that only one user experience is provided, this would mean that e.g. that Alice (who initiates the call) user experience is ported to Bob, once he accepts the call.
#2 H2H Communication UC