From c8456d57ff757afaf77478e71cf140740fe520d3 Mon Sep 17 00:00:00 2001
From: erik <erik.seiert@meissa-gmbh.de>
Date: Thu, 30 Nov 2023 16:10:26 +0100
Subject: [PATCH] Add thoughts on user creation

---
 routers/api/v1/activitypub/repository.go | 30 ++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/routers/api/v1/activitypub/repository.go b/routers/api/v1/activitypub/repository.go
index 3250c00166..1220d9838e 100644
--- a/routers/api/v1/activitypub/repository.go
+++ b/routers/api/v1/activitypub/repository.go
@@ -130,9 +130,39 @@ func RepositoryInbox(ctx *context.APIContext) {
 	log.Info("http client. %v", client)
 	log.Info("response: %v\n error: ", response, err)
 	log.Info("Person is: %v", person)
+	log.Info("Person Name is: %v", person.PreferredUsername)
+	log.Info("Person URL is: %v", person.URL)
 
 	// create_user_from_person (if not alreaydy present)
 
+	/*
+		ToDo:
+		This might be a forgefed specification question?
+
+		How do we identify users from other places?	Do we get the information needed to actually create a user?
+		E.g. email adress seems not to be part of the person actor (and may be considered sensitive info by some)
+		cmd/admin_user_create.go seems to require an EMail adress for user creation.
+
+		We might just create a user with a random email adress and a random password.
+		But what if that user wants to create an account at our instance with the same user name?
+
+		Or might it just be easier to change the data structure of the star and
+		save identifying info of a remote user there? That would make the star structure quite bloaty though.
+		It would also implicate that every other feature to be federated might need their own struct to be changed.
+
+		Or create a federated user struct?
+		That way, we could save the user info apart from any federated feature but tie it to that.
+		On a new registration we could check whether that user has already been seen as federated user and maybe ask if they want to connect these information.
+		Features to be federated in the future might benefit from that
+		The database of federated features will have to be updated with the new user values then.
+
+		The "if not already present" part might be easy:
+		Check the user database for given user id.
+		This could happen with something like: user_model.SearchUsers() as seen in routers/api/v1/user.go
+		SearchUsers is defined in models/user/search.go
+		And depending on implementation check if the person already exists in federated user db.
+	*/
+
 	// wait 15 sec.
 
 	ctx.Status(http.StatusNoContent)