Replies: 6 comments 7 replies
-
|
It would be nice to download your chat log. That would mean the user, not the admin, would have control of their chat and history. |
Beta Was this translation helpful? Give feedback.
-
|
I see the value of a download feature, but I would like to call out that the chat history will just allow you to view the history offline as reference. Another feature I have in mind is account migration. An account should be able to migrate from one server to another and bring the conversations with them. |
Beta Was this translation helpful? Give feedback.
-
|
That is better than what I can think of |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand anything at all: |
Beta Was this translation helpful? Give feedback.
-
|
there is quite a lot to answer in your message. I will do my best to respond, but please follow up with more questions where I can explain further: To create an e2ee topic, you need to go into settings and click 'manage sealed topics'. This will create a private key that will be used in the establishment of e2ee topics. You need to choose your password for your key, this will allow you to unlock that key on another device, allowing you to use multiple devices. To communicate e2ee with someone else, they need to also setup their key. There is an admin setting for 'allow unsealed topics', effectively leaving the decision around default e2ee up to the admin. The server provides a restful API, so it's not so much a wire protocol; it's an API built on top of HTTPS. The e2ee encryption is achieved through the standard approach of having a distributed public key (RSA) that encrypts a symmetric key (AES), which is then shared among the participants. The participants can recover the symmetric key by decrypting with their secret private key. There is nothing proprietary about this approach and is commonly used in web servers. The double-ratchet algorithm does provide additional security such as forward secrecy. Perhaps we will support that algorithm in the future, but we opted for the flexibility of our current approach. To the question as to what this messenger solves, I need to to describe the long term ambitions of this project. The hope is for it to one day provide a mainstream tool for people to own their data and communicate with privacy. There are plenty of successful projects that go a long ways in that effort, and perhaps this will never be as successful as those, but the initial approach of this project attempts to address the perceived ceiling of those projects.
The thought with Databag is not that these barriers are solved, but there is plan to overcome them. The Knowledge Barrier is addressed by initially supporting low cost CE devices such as the Raspberry PI. Ideally something like an OpenWRT router can be purchased supporting Databag at a low cost. If a person can setup a router, they should also be able to setup Databag. Perhaps one day a provider like PikaPod can also offer an instance. The Resource Requirement is addressed in the software design. Each instance is passively responding to a restful interface and there is no server side synchronization. There is no risk of an account connecting to a huge channel requiring massive data synchronization. Currently an instance runs well on a standard home area network. The Interoperability is addressed by providing an SDK and eventually establishing a non-profit to provide interoperability certification for hardware. Databag intends to be a data sharing network not strictly for chatting. The current network should enable sharing of photo albums, calendars, etc. Eventually the network will evolve to support more use cases such as social media. The Network Effect is addressed not through a single perfect service, but through incremental growth. Initially the early adopters will use the messaging service and are very technical or close to someone that is. In the near future we plan to add other services such as photo sharing, music sharing, calendar sharing, etc. Hopefully some OSS developers will build their own. These should have an incremental growth effect. Each new service adds to the overall value of the network in terms of people and functionality. Simultaneously we are working on an OpenWRT build with Databag that could reach a larger non-technical audience. The dream is one day a 3rd party CE company might want to sell a Databag enabled device. Thanks for your interest in the project. |
Beta Was this translation helpful? Give feedback.
-
|
FYI I am concerned of project’s ability to gain traction due to source code 1st approach. Hopefully the author is aware of nostr project. I don’t know its history, but it takes spec 1st approach: https://github.com/nostr-protocol/nips Nostr already has dozens of server and client implementations, due to its simplicity and selective NIP support model. Because of spec 1st approach, it is easier to trust protocol level design claims related to security and data privacy. I personally tried nostr and can’t quite decide if I like its universe. I like the simplicity with which it starts. There are good and bad sides to it. The best feature of this project is the ability of the content creator to choose who has access to the content. I assume there will be public alias at some point. I like the architecture to support the privacy. Hubzilla (older) and streams (experimental) projects are closest to this one IMO: https://hub.netzgemeinde.eu/display/b64.aHR0cHM6Ly9odWIubmV0emdlbWVpbmRlLmV1L2l0ZW0vYjRiMGE3OGUtMzUzMC00NTQ3LTg4MWItMzBlMmI2MzMwOTVl Streams is basically an effort of very few people. There are authentication claims, but spec is not really available (at least about 9 months ago) and one has to read php code to understand streams protocols. I see this project taking route of streams project with low adoption rate, unless NIPs approach is taken. There’s nothing wrong with that. nostr has multiple aspects:
but it doesn’t seem to have fine grained access control of this project. Perhaps your experience in this project can result in another NIP to brige the gap? I am not nostr expert, I might be wrong here about it. Another side of a spec approach is XMPP universe of confusion, so there’s no one size fits all. That’s where single implementation is better. To summarize:
|
Beta Was this translation helpful? Give feedback.
-
|
I hadn't been following nostr and happy to see how well they are doing. I am curious how it supports the private messages and can be used for typical chatting. From my understanding it would not be compatible and therefore not achievable through a nip or relay. I agree with what you say about XMPP, some clients work best with specific servers. Ideally they should work with any server. I also agree that a more formal spec would help databag's chances, but I also have to consider my limited resources. For me this meant treating this like an agile project. First identifying a vertical slice through the whole system and then iterating outward. For databag the vertical slice was instant messaging. Each iteration of the vertical slice means investing my resources in the area that will most benefit the project in the near term. Recently this meant building a client SDK. Please let me know if I didn't address some of your points. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
The following quote is from https://lockbox.fiatjaf.com/:
The approach is not exactly a permission group, but an interesting concept nevertheless. The source code for the website: https://git.fiatjaf.com/lockbox It appears there is a group NIP, but I have not seen it in details. |
Beta Was this translation helpful? Give feedback.
-
|
There is NIP-29 effort, which allows for public and private groups. Here is NIP 29 relay and NIP 29 client. |
Beta Was this translation helpful? Give feedback.
-
|
From this, it seems like some form of private communication should be achievable. I'll look further to see if other features like push notifications and message editing are also possible. Reading that part of the spec includes a "hack" leaves me a little pessimistic. In my opinion a protocol should be pure mechanism as simple as possible. Making a protocol so expansive inhibits implementation and interoperability. That being said, I like the overall design of nostr and I'd love to see the project succeed. |
Beta Was this translation helpful? Give feedback.
-
|
They also have file storage spec, so there seem to be all the bits and pieces in place. For the scope of this project to be successful, it will have to be clear that its client works only with one relay. fiatjaf on nostr in one of the articles commented, that the original nostr design goal was a person posts to a specific relay and then when people follow, their smart client connects to relays of individual people they follow. The model is still largely the same, but it diluted by the fact that clients these days post to multiple relays. In the multiple relay post model, it is difficult to be certain that security restrictions are enforced. But, this project does not have to follow this model. I would say it should not, if it uses relays for data storage. I'd go for custom relay server, based on some of the existing. Ideally, existing server functionality will be sufficient. Once there is a relay, that can enforce group policies, it becomes a task of making a good UI for that functionality. The UI would use just one relay server as well. I might be simplifying the task, but it is worth considering. I don't see a problem with client working with a single relay approach, because there is still a good support from generic nostr tooling. These tools can pull user data from the the relay, if user decides to get a copy of his or her data. The problem I see today with nostr is a huge selection of tools, but tools fall short when private and public groups are concerned. That's probably because the feature is in active development. It might be a good time to provide feedback from this project's perspective. Please understand, that I am just providing feedback and what I have seen on this project is already quite nice. I know I cannot contribute the development time. These comments is all I can do. It is just an issue of one man resource and it would be nice to be able to leverage existing infrastructure. Saved time can be spent on UI client work. It is just my 2c. here. What I seem to look for is private content for most of the content. Some of the content I want to share:
The content can be anything: my thoughts as a note, image with my comment, video with my comment. The advantage of nostr, is that when I share content as public an existing network can pick it up. Of course, there are bridge style solutions, so it is not the only way. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I am a bit confused on interoperability. If to provide the messaging requires a custom relay, then federated messaging would require a network of custom relays? Is the solution basically implementing the current databag api within a nip? It's hard to understand what part of the nostr network could be leveraged? |
Beta Was this translation helpful? Give feedback.
-
My take is the leverage mostly in using Any unusual data types can be covered by non-standard note types. I have not looked in detail into this. Group chats are taken care by related nips. What I see is a custom app, leveraging existing It is just an idea. The owner is the one who decides what product is going to look like. I don't think I have more to add for this topic. If you want to discuss some details privately, my Revolt User ID is Kulak |
Beta Was this translation helpful? Give feedback.
-
The vision of Databag is to provide a platform that empowers the individual. With Databag, people have full privacy and control of their data. People authorize services to access their data for the value they add, but there is no lock in. Any service violating the trust of the community or providing a poor experience gets locked out and replaced.
People maintain the privacy and contol of their data by controlling where that data is hosted. This can be as easy as signing up for a cloud service or buying a router supporting Databag, while the tech savvy may choose to self-host with a container running on their home PC. The direct control over their data means that people can control how and when that data is accessed.
Services operating in the Databag network can only monetize the value they bring. Unlike a centralized service, where their users are locked in, they cannot exploit their position and monetize the true product, the users themselves. With a smaller upside there still is an opportunity for developers; the barrier of entry is much lower. The network effect only needs to be overcome once. The network effect in Databag is not overcome by a single service with exponential growth, but incrementally by each service that adds value to the network, increasing the network size and in turn adding value to all the other services.
At it's core Databag is an API for sharing data over a federated and decentralized network. As Databag matures it will operate as a non-profit tasked with certifying services and hosting entities and growing the network capabilities. Currently the API focuses on personal communication, supporting services like messengers or shared photo albums between people with a personal connection. The network will however grow to support impersonal communication as we have with social media, but will do so without violating its principles.
Beta Was this translation helpful? Give feedback.
All reactions